W internecie i nie tylko aż roi się od stwierdzeń typu „Java jest 20 razy wolniejsza od C++„. Wielu użytkowników zawzięcie dyskutuje za i przeciw użyteczności aplikacji wykonanych w Javie oraz rzeczywistym wpływie użytego języka na wydajność końcową. Ile w tym prawdy i jaki jest rzeczywista różnica w wydajności między Javą a innymi językami? Czy Java jest faktycznie wolniejsza od C++ czy to tylko kolejny mit powtarzany od lat?

Różnice techniczne

Języki takie jak C, C++ są kompilowane do kodu natywnego, gdy się uruchamiają, działają bezpośrednio na procesorze. Tym samym jednak są od razu przypisane pod konkretny system i konkretną architekturę procesora. Języki interpretowane likwidują ten problem: kod jest w pełni przenośny dzięki temu że kod jest czytany na miejscu, powoduje to jednak znaczny spadek szybkości, rzeczywiście czasem nawet 20-krotny. Ale czy Java jest językiem interpretowanym? Była. Pierwsza wersja, wtedy właśnie narodziło się najwięcej takich bzdur, które przetrwały do dziś. Jak wygląda proces tworzenia aplikacji w Javie?

Proces budowania i uruchamiania aplikacji w Javie

Omówię to na przykładzie oficjalnej implementacji. Mając plik .java z klasą, kompilowany jest on do pliku .class – kompilowany tak samo jak w C++, tyle że nie do Assemblera, tylko tzw. bajtokodu – można go nazwać „assemblerem maszyny Java”. Te pliki .class nie są assemblowane i linkowane, tylko zazwyczaj pakowane do archiwum zip o rozszerzeniu .jar wraz z tzw. manifestem – nagłówkiem, który informuje gdzie się program zaczyna i jakie biblioteki ma dodatkowo załączyć. A jak wygląda uruchamianie? Kiedyś maszyna rzeczywiście czytała linijka po linijce wykonując poszczególne instrukcje. A jak to wygląda teraz?

Just-in-Time Compiler

Wirtualna Maszyna Javy (JVM) wyposażona jest w tzw. kompilatora JIT. Jego zadaniem jest zoptymalizować kod pod daną platformę, na której aplikacja jest uruchamiana. Dzieje się to dopiero po uruchomieniu aplikacji. Wadą tego rozwiązania jest ciężki rozruch, zaletą – przenośność, nieważne na jakiej maszynie kod został skompilowany, uruchomi się na każdym procesorze i systemie (o ile nie użyto zewnętrznych natywnych bibliotek). Spora część instrukcji przenoszona jest z wirtualnej maszyny na fizyczną – procesor, dzięki czemu kod przyspiesza. Ile?

time java Test<data>output

Nie, nie, i jeszcze raz NIE! Jak wspomniałem, JIT zaczyna robić swoje dopiero po uruchomieniu, więc sprawdzenie czasu wykonania całej aplikacji jest… niesprawiedliwe. W tym czasie aplikacja jeszcze się kompiluje, to tak jakby mierzyć czas programu w C poprzez time gcc test.o && ./a.out.

Przykład: wyznacznik macierzy 10×10 metodą rozwinięcia Laplace’a. Stosowana jest rekurencja i częsta alokacja/dealokacja pamięci (10 wykonań).

C++ (z -O2): 2,700s
Java: 3,700s

Czy to jest aż 20 razy więcej? Poza tym, wyniki cząstkowe:

 time: 490.904373
 time: 374.741364
 time: 353.051288
 time: 351.861573
 time: 362.405451
 time: 352.954302
 time: 348.976093
 time: 346.036781
 time: 357.956662
 time: 339.504749
 sum time: 3700.863812

Jak widać pierwsze wywołanie trwało najdłużej – JIT jeszcze wtedy nie zdążył skompilować bajtokodu do kodu maszynowego. Tu dużą rolę odgrywała rekurencja, a w niej: tworzenie tej klasy od nowa, a przy tym: wcześniejsza jej kompilacja. Kolejne próby są już jakby „pełnej szybkości”, czyli ok. 345ms, podczas gdy C++ potrzebował na to 270ms. Około 30% straty wydajności.

java wykres porownania wydajnosci

Wykonałem również test wyłączając JIT (opcja uruchomienia -Djava.compiler=NONE), obliczenie całości trwało 33 sekundy, czyli 3,3s na jedną macierz.

Wziąłem również przykład sortowania bąbelkowego:

java wykres porownania wydajnosci

C++ (GCC z -O2 i -O3) wykonał zadanie w 2,1 sekundy. W Javie ten sam kod (nieco zmieniony, żeby się skompilował w Javie) zajął 3,6 sekundy. Ale czy na pewno? Zmierzyłem czas wewnątrz programu dla drugiego wykonania sortowania: 1,6 sekundy! Ten sam algorytm w Javie wykonał się szybciej! W tym teście mam pewność, że drugie wykonanie jest już po pełnej kompilacji, a pierwsze nie: w algorytmie liczenia wyznacznika macierzy w trakcie obliczania pierwszego kompilował całą klasę do kodu maszynowego, przez co różnica jest niewielka.

Ale ale. Wykonałem też test tego algorytmu w C++ z użyciem clang i Open64. Oba osiągnęły wyniki w okolicach 1,6 – 1,7 sek. W przypadku programu z macierzami najlepiej wypadł GCC, więc reszty nawet nie pokazywałem. Nie będę tu nawet zamieszczał moich wyników testów z gcj – natywnym kompilatorem Javy z GCC. Te wyniki są po prostu… fatalne względem OpenJDK, którego używałem w tych testach.

To nie język jest szybki, to implementacja

Powtarzałem to już wiele razy, język jest tylko językiem, programy tworzą kompilatory. Java z pozoru może wydawać się wolna, w końcu jest to język zarządzany działający w maszynie wirtualnej (JVM). Jednakże optymalizacje stosowane przez tą maszynę i JIT potrafią przyspieszyć ten kod. Podobna technika jest stosowana w .NET i C# (Osobiście uważam że ten język nie powinien mieć C w nazwie: jest to mylące, to nie jest język będący „forkiem” C, tak jak C++, tylko całkiem odrębna technika na wzór Javy). Tak więc o ile czasy w krótko działających programach mogą być stosunkowo większe, to w długo działających aplikacjach użytkowych cały kod po pewnym czasie jest całkowicie kompilowany do kodu maszynowego i różnica ta staje się niewielka, o ile nie porównuje się z aplikacjami używającymi zaawansowanych funkcji procesora, do których Java dostępu nie ma z wiadomych względów (założenie przenośności kodu).

W Javie szybkość nie jest już aż takim problemem jak kiedyś. Są nawet sytuacje kiedy jest nawet tak samo szybka co odpowiednik w C++. Co prawda jest spadek wydajności w stosunku do C++, jednak aplikacje pisze się znacznie szybciej i łatwiej oraz łatwiej znaleźć błędy. W przypadku aplikacji użytkowych taki spadek wydajności nawet nie jest zauważalny.

Nie mówię, że w Javie można spokojnie pisać wielkie wymagające komercyjne gry, bo nie do tego ten język został stworzony. Owszem: małe, mało wymagające można śmiało napisać w Javie, przykładem jest chociażby Minecraft. Dlaczego czasem tnie? Wbrew pozorom grafika w tej grze jest bardzo skomplikowana i to ona zżera najwięcej czasu. Klony w C++ chodzą niewiele lepiej, a mają znacznie mniej zaimplementowanych elementów świata. Ten krótki test nie miał na celu zbadania konkretnych czasów, nie był benchmarkiem, tylko dowodem na to, że źle przeprowadzony test może doprowadzić do niepoprawnych wniosków.

Poprzedni artykułKodek dźwięku Opus otrzymał standard RFC 6716
Następny artykułParted Magic 2012_09_12

97 KOMENTARZE

    • RAM na serwerze może i jest tani i klient ci przytaknie. Ale jak śmiesz tak nonszalancko szastać pieniędzmi użytkowników desktopów, którzy przez takich bałwanów co chwila muszą wymieniać sprzęt, bo przecież "jest tani" i tańszy od twojego bezcennego czasu?

    • To inna sprawa. Ale dopóki to zamawiający płaci: za RAM/sprzęt albo za czas pracy programisty, to jest OK.
      Gorzej, gdy firmy tworzące oprogramowanie oszczędzają na SWOICH kosztach programistów przerzucając koszty sprzętu na Bogu ducha winnego użytkownika końcowego. To jest chamstwo, brakoróbstwo i dno technologiczne.

    • Pod warunkiem że masz zwykłe DDR3 a nie DDR2 z ECC. Więc nie bierz pod uwagę tylko zwykłych desktopów bo prawdziwe serwery nie korzystają z pamięci non-ECC.

    • Nie do końca. Problem z GC w Javie jest m.in. taki, że na serwerach z np. 32 GB RAM-u potrafi zatrzymać proces na kilka minut, jak już zacznie odśmiecać. To najczęściej niedopuszczalna sytuacja, więc robi się obejścia w postaci osobnych mniejszych procesów i częstym ręcznym wywoływaniem GC.

      Java to generalnie język, który chyba nie ma dobrego zastosowania. Na telefonach muli, na desktopie muli, na serwerach muli.

    • IMO pamięć RAM nie jest aż takim wielkim problemem w dzisiejszych czasach. Poza tym JVM lubi zeżreć sobie "na zaś", by nie prosić systemu o więcej, tylko od razu użyć. Jak tak patrzę na IDE to faktycznie zajętej pamięci jest 20-50% tego, co zostało zarezerwowane. Ja tam mogę sobie pozwolić na uruchomienie jednej aplikacji z rezerwą na kilka GiB, RAM jest tani prawie jak barszcz, nawet dla laptopów (80 zł za 4GiB DDR3 dałem) :)

      Taki Minecraft po 10 minutach gry: w OSie zajmuje 600 MiB (zarezerwowane niby 1200MiB), w JVM zaalokowane tylko 25%. java mogłaby mniej RAMu żreć, ona po prostu żre tyle ile może sobie pozwolić.

    • RAM jest problemem kiedy zaczynasz się skalowanie. Może na domowym komputerze to faktycznie nie stanowi problemu dla kogoś majętnego. Ale w firmie gdzie jest np. 100000 komputerów to już sprawa ma się inaczej.

    • I ciekawe, że właśnie tam wybierają Javę. Lepiej byłoby tylko w C lub C++ ale jak to napisać?

    • Gówno prawda, w dzisiejszych czasach, często uważa się na zasoby, możesz tego nie wiedzieć, bo patrzysz przez pryzmat komputera osobistego, ale inaczej patrzy producent, przypuśćmy panasonic, samsung itd który na rynek chce wypuścić minimum 20 milionów urządzeń, a każde z nich musi mieć pamięć. Wtedy dopiero zaczynasz obcinać koszty i robić niskopoziomowo w C!

    • To, że „ajfony” mimo często gorszych parametrów działają płynniej to fakt. Przycięcia nawet głupiego UI zdarzają im się nieporównywalnie rzadziej niż Andkowi.

    • Aplikacje pisane w na iPhone’y działają super płynnie tylko dlatego, że są pisane pod konkretną architekturę. Na Androidzie nawet na nowym telefonie zdarzyło mi się, że aplikacja się zawiesiła czy wywaliła, od tak po prostu, co jest strasznie uciążliwe, kiedy przychodzi gdzieś na szybko zadzwonić albo coś sprawdzić. Na szczęście teraz mam telefon z Windows Phone, a tutaj nie ma mowy o zawieszeniu programu.

    • Hehehe… a mi się udało zobaczyć zawieszenie, i to całego systemu, mało tego nawet nic nie robiłem na nim tylko z kieszeni wyjąłem…infaltylne jest twierdzenie , że skomplikowanie oprogramowanie nie ma błędów.

    • Jeżeli Java jest wolna to co powiedzieć o Pythonie? Java jest 10-20% wolniejsza od C, a Python jakieś 40 razy. A przecież w Pythonie napisanych jest sporo aplikacji w Linuksach i nie ma tak złej sławy jak Java.
      Java słabo nadaje się na desktopa bo dość długo startuje i zużywa sporo pamięci, ale pozwala pisać duże systemy, które bardzo trudno napisać w językach kompilowanych do natywnego kodu.
      Niech każdy język będzie wykorzystywany do tego do czego się najlepiej nadaje. :)

    • I to pewnie jest kluczowe. Java goniąc za szybkością jest bardzo agresywna w zajmowaniu pamięci.
      Do tego brakuje dobrego bindingu do Gtk.

    • Ale był dość popularny do Qt. Teraz chyba rozwijany dalej przez społeczność.
      Agresywna Java to nic w porównaniu z V8, gdzie przy obliczeniach GC zabiera sobie na chwile 500 MB a potem nagle oczyszcza do 50.

    • Akurat status Qt Jambi jest dosyć… niepewny (dawno nie było rls, kod w repozytorium lubi nie działać, itp.). Ogólnie, jak ktoś chce robić GUI, to lepiej nie w Javie.

  1. AKtualnie implementacja JDK z Oracle to tzw. HotSpot VM – kompiluje te fragmenty kodu, któe zostały uznane za optymalizator za "godne kompilacji". Jednocześnie ta technika nadal wymaga dostepu do bytecode (z uwagi na operowanie klasą i inne aspekty), więc ilość pamięci wzrasta. tak czy inaczej, Java wcale ne jest taka wolna :)

  2. Ludzie mają złe mniemanie o Javie przez to, że applety takie jak np. Czateria wolno im się uruchamiają. Ale JVM to jak system operacyjny, w którym działa program. Java jest przenośna (.NET nie a miał być). Javę wykorzystuje się na serwerach i chodzą na tym bardzo duże i szybkie serwisy. Java jest szybka!

    • I mają prawidłowe mniemanie. Serwery to inna sprawa, tam za sprzęt płaci ta sama osoba, która zamawia oprogramowanie i godzi się na jego powolność.

    • Chłopie napisz kiedyś duży serwis internetowy w C++ to porozmawiamy. Ciekaw jestem jak by wyglądał internet gdyby wszystko pisano w C++ :)
      Sądzisz, że różne instytucje finansowe, żałowałyby kasy gdyby mogły uzyskać lepszy wydajniejszy system w C++? W bardzo dużych systemach drogi sprzęt nie pomoże za wiele, popatrz na system Millenium dla giełdy.

    • Nie to bym był jakimś znawcą czy coś. Ale takie serwisy internetowe to zazwyczaj na jakiś serwerach chodzą, a na tych serwerach to jakieś systemy operacyjne zwykle pisane w C lub C++. Ja jestem opinii, iż gdyby wszystko pisano w C++ chodziło by sprawniej. Firmy o których mówisz są za biedne by móc korzystać z C++, a nie odwrotnie. C# czy Java są tak popularne gdyż w krótkim czasie można wyszkolić programistę i zaciągnąć go do kodowania.

      A poza tym zwykłego śmiertelnika nie interesuje to czy Java jest wolna czy szybka. Jemu zależy na tym by działało. A klient czy sprzedawca patrzy najpierw na cenę.

    • System operacyjny to zupełnie co innego niż aplikacja webowa. Gdyby musiała istnieć tylko jedna lub najwyżej kilka aplikacji webowych to pewnie w końcu ktoś napisałby w C :) Pewnie gdyby byli ludzie i czas to systemy operacyjne lepiej chodziłyby gdyby pisano wszystko w assemblerze.
      Żeby napisać w C/C++ to trzeba by w pewnie z 10 razy więcej czasu. Do C++ nie ma nawet porządnych frameworków webowych. A i tak przy przekroczeniu pewnego poziomu skomplikowania projektu można się zgubić.
      Java nie jest wcale łatwiejsza do nauczenia się niż C++ (nie mówiąc już o prostym C), żeby dobrze pisać trzeba sporo wiedzieć. Za to Java pozwala pisać znacznie szybciej i nie przejmować się zarządzaniem na niskim poziomie pamięcią. Dorobiła się już tylu różnych narzędzi, że daleko wyprzedza rozwiązania z innych języków. Dzięki temu łatwiej i szybciej napiszesz dużą wielowątkową aplikację, działającą na różnych maszynach.

      A kogo na przykład interesuje, że PHP jest wolny? Na typowych stronach internetowych najsłabszym punktem i tak jest szybkość bazy danych.

    • Czyli jak to jest to firmy są za biedne czy C za trudne ? Bo prócz oczywistych oczywistośći w powyższym poście nie niesie on żadnej merytorycznej treści.

      Poza tym twoje wypowiedzi się negują. Jeśli Java nie jest łatwiejsza, to by znaczyło iż jest trudniejsza bądź conajmniej tak samo trudna jak nauka C to dlaczego przy dalszych założeniach, iż nie należy się przejmować zarządzaniem pamięcią. Przecież jeśli czegoś nie trzeba się uczyć to w teori jest to łatwiejsze. Ale NVM.

    • Widać, że nie zajmujesz się programowaniem. :)
      C łatwo się nauczyć, korzystać z bibliotek już znacznie trudniej. Java ma bardziej rozbudowaną składnię wiec opanowanie jej zajmuje dłuższy czas.
      Można by porównać pisanie programów do stawiania budynków. Małe cegły dają dużo większe możliwości dopasowania kształtu (w programowaniu również mogą dać większą wydajność). To symbolicznie język C.
      Duże gotowe prefabrykaty z betonu, pozwalają łatwiej budować olbrzymie budowle (Java). Małe cegły nie pozwalają szybko budować, a po drugie trudno jest utrzymać kształt budynku.
      W C diabeł tkwi w szczegółach, masz mniej elementów, ale możliwości ich składania i konstrukcje są nieograniczone. W Javie masz olbrzymią ilość elementów z których składasz program, musisz więc mieć większą wiedzę. Żaden z nich nie jest łatwiejszy czy trudniejszy w używaniu, bo to zależy od projektu którego się podejmujesz. I każdy z tych języków nadaje się do czegoś innego. Poza tym, każdy z tych języków wymaga nieco innego spojrzenia na programowanie. A według mnie to szybciej można wyszkolić programistę w C i zaciągnąć go do kodowania niż w Javie. Inna sprawa, że jakość tego kodu i tak będzie marna bo w sumie, aby kodować na poziomie to niezależnie od języka wymagane jest duże doświadczenie.

      Masz dobre zadatki, żeby być informatykiem, bo rozumujesz bitowo :) Napisałem wcześniej, że Java nie jest łatwiejsza, ale nie napisałem przecież że jest trudniejsza.

    • W C++ też nie trzeba przejmować się pamięcią. C++ ma uniwersalny system do zarządzania zasobami, w tym pamięcią. Java natomiast ma GC, który nie dość, że potrafi się zablokować proces na dłużej, to jeszcze w Javie tak naprawdę da się zarządzać _tylko_ pamięcią. Wszystko inne – deskryptory plików, muteksy i inne pierdoły trzeba zwalniać w Javie ręcznie. Jak zapomnisz – to se szukaj wiatru w polu. Generalnie C++ jest znacznie lepszy pod tym względem od Javy, to że GC jest rozwiązaniem to jest jakiś często powtarzany mit.

      No i wątpię, żeby w C++ pisało się wolniej niż w Javie. Po prostu do C++ nie powstały frameworki do WWW.

    • C++ jest znacznie bardziej skomplikowany niż Java, no i dobrzy programiści C++ bardziej się cenią. Wydajność to nie wszystko. Trzeba liczyć całą ekonomię.

    • Znam jeden system bankowy napisany w archaicznym już języku. Wszystko fajnie. Niby to jest wydajne ale:
      – nie ma programistów, którzy to będą rozwijać
      – jak są to są bardzo drodzy
      – zmiana czegokolwiek zatem jest niemożliwa
      Firma doszła do wniosku, że taniej będzie to przepisać na Javę z wykorzystaniem systemów integracyjnych niż utrzymywanie szybkiej aplikacji, z którą nie da się nic robić.

  3. Artykuł jak znalazł. Właśnie migrujemy aplikację z PHP(Zend)+APC+Redis i inne cuda na Javę. Nie dość, że daje nam to pełną skalowalność to jeszcze działa szybciej. Takie głupie PHP przy praktycznie każdym requeście musi się od nowa interpretować. Niby jest APC (zjada pamięć), ale nie zawsze działa stabilnie.

    • Facebook uważa, że kompilacja PHP daje jakieś 50% przyrostu wydajności. To z jednej strony dużo (mniej serwerów), ale w porównaniu do Javy niewiele. Dobrze, że nie używacie Hibernate bo aplikacja w Javie z jego użyciem traci sporo na wydajności.
      PHP nadaje się lepiej do mniejszych stron bo nie siedzi cały czas w pamięci kontenera.

    • Korzystanie z Hibernate jest wygodne od strony programowania, natomiast fakt… wydajność ;-) Bardzo często od strony Oracla można było oglądać bardzo dziwne zapytania generowane przez Hibernate. Zawsze jest coś kosztem czegoś. Albo aplikacja jest łatwa w rozwijaniu i tniemy koszty developmentu i rosną nam koszty utrzymania, albo odwrotnie.

  4. Gdy muszę korzystać z tagiego programu jak jdownolader napisany w javie to krew zalewa. Jeszcze nigdy się poprawnie nie wyłączył tylko trzeba zabijać proces. Dobrze że są inne zamienniki takich programów. Osobiscie wolę programy pisane w C/C++.

    • Gdy muszę uruchomić coś napisanego w .NET to krew mnie zalewa. Różnica jest taka, że aplikacja w Javie pisana jest pod JVMa a nie pod system operacyjny, więc jest przenośna. Coś za coś ;-) Ale widać nie każdy rozumie po co, dlaczego i jak działa Java.

      Osobiście wolę programy pisane w assmeblerze z komentarzami pisanymi w kaszubskim.

    • Z tą "mobilnością" JAVy to tak mocno bym nie szarżował bo aplikacja napisana pod jeden numerek JRE (czyli tego co umożliwia odpalenie softu na innym komputerze ) działa tylko na nim bo po aktualizacji JRE aplikacja może się wyłożyć na plecy i machać nogami. Jeśli by aplikacje napisane w JAVIE były przenośne to powinienem wziąć "exeka" i odpalić go na linuxie . Może czegoś nie wiem ,ale jeszcze nie spotkałem takiej aplikacji

    • Kwestia definicji przenośności. Zazwyczaj przenośność definiuje się dla kodu źródłowego, a nie pliku wykonywalnego. C jest przenośne bo można kod źródłowy kompilować na różne platformy, Java tym bardziej. Fakt, że aplikacje napisane w Javie uruchamia się bez jakiejkolwiek zmiany w kodzie źródłowym na różnych systemach świadczy o przenośności, choć obecnie Java nie ma wyłączności w tej dziedzinie.

    • Dziwne mi napisana aplikacja "hello world" nie działała na telefonie gdzie też była JAVA SE a na kompie działa :P

    • Widocznie programiści JDownloadera spaprali sprawę, bo jakoś moje aplikacje zamykają się bez problemu. O jakości softu nie decyduje użyta technologia, tylko umiejętności programistów. A użyli Javy zapewne dlatego, że ten program w dużej mierze opiera się o pluginy, które przy użyciu Javy są bajecznie proste w użyciu, podczas gdy w C++ musieli by napisać 2 razy więcej kodu, by móc w ogóle dodawać pluginy.

    • Nic dziwnego, bo najzdolniejsi programiści Javy mają tak dużo pracy w korporacjach, że nie mają czasu pisać aplikacji dla desktopa. Więc piszą tylko amatorzy ;)

    • Ja się podpisuję. JDownloader uruchamia się u mnie prawie tak długo co cały Linuks Mint. Ogólnie jak tylko mogę to unikam aplikacji w Javie… Niestety coraz trudniej o to.

  5. Trochę lipny ten test wykonany przez autora. Lepiej było przeprowadzić dłuży test, i zwłaszcza nieliniowy(choć nie wiem czy rozwinięcie LaPlacea takie nie jest). Jestem pewien, że różnice były by znacznie większe.
    Po za tym uważam, że Java z najnowocześniejszych języków jest najbardziej 'toporna'. Programy w niej napisane są mniej responsywne i powolniejsze niż w innych językach. Zwłaszcza te większe.

    Sam język i programowanie w nim jest jak najbardziej w porządku.

    • Mam zupełnie odwrotne odczucia. Nie zauważyłem nigdy problemów z działaniem JVM (może poza GUI), natomiast "sam język i programowanie w nim" to mordęga. Całe szczęście, że powstają te wszystkie Scale, itd.

  6. Gdzie jest kod źródłowy testów? Znowu artykuł z benchmarkiem bez podstawowego elementu.

    ""Ten krótki test nie miał na celu zbadania konkretnych czasów, nie był benchmarkiem, tylko dowodem na to, że źle przeprowadzony test może doprowadzić do niepoprawnych wniosków.""

    Tytuł w takim razie powinien brzmieć "źle przeprowadzony test może doprowadzić do niepoprawnych wniosków" ale tu się kłania Captain Obvious.

    • Proszę, oto źródła (poza tym wyświetlającym poszczególne czasy, bo nie pamiętam gdzie to miałem, to wyniki z moich testów porównawczych Java – Scala): http://www.sendspace.com/file/4bu03y. Nie chciało mi się tego pakować do formy czytelnej dla innych, testy przeprowadzałem tutaj akurat ręcznie, bez pomocy skryptów, dokładne wartości nie były aż tak ważne. To ta sama macierz, co przy tamtym teście. Przy tamtym benchmarku jedyne 2 testy do których nie mieliście dostępu to właśnie ta macierz i sha-1 (choć i ten to pierwszy lepszy wynik google'a dla "sha-1 C++" + jakiś ~200MiB plik), do benchmarka adobe'a dałem link, a zarówno POV-Ray jak i Lame są OpenSource i każdy ma dostęp do ich źródeł.

  7. Słaby artykuł, napisany przez kogoś kto nie ma pojęcia o JVM, tym bardziej o programowaniu nań. Podobnie jak C++.

    Aby był sens w prowadzeniu testu to powinny być spełnione kilka warunków.

    1. Duże liczby. Testy rzędu 2 sek nie są żadnymi testami.
    2. Jeśli porównujemy dwie rzeczy badajmy to co faktycznie jest stosowne a nie całość i to przy wykorzystaniu odpowiednich narzędzi. A nie tego co nam się pod rękę nawinie.
    3. Poza tym co można udowodnić różnymi implementacjami podstawowych algorytmów ?

    Tak. Artykuł dowiódł, iż źle przeprowadzony test może doprowadzić do niepoprawnych wniosków. Np. Jak pomysł opisania.

    A jeszcze co do C#.
    Zasadniczą różnicą między C a C++ jest to, że co możesz w C++ nie możesz w C ale co możesz w C możesz w C++. Dlatego też początkowo język ten był znany jako C plus Classes, Co daje c+c, co przerodziło się w c++. Sam # oznacza krzyżyk w muzyce czyli tonację wyżej. Zatem C# jest wzmocnionym C++. Trudno nie zgodzić się z takim stwierdzeniem.

    Plus za starania, minus za podejście do tematu.

  8. Wojny tego typu zawsze będą dopóki ludzie nie zrozumieją, że to tylko narzędzie do pracy. Perl czy Python? Windows czy Linux? PHP czy Java? Takie porównania co jest lepsze nie mają sensu.

    Mogę napisać artykuł dlaczego śrubokręt jest lepszym narzędziem od młotka, bo np. lepiej wkręca się nim śrubki, ale to nie o to chodzi. Ci co tak podchodzą do tematu powinni być kastrowani na początku.

    JAVA nadaje się do zastosowań głównie biznesowych. Stoją na tym potężne serwisy co obsługują milionowe ilości zapytań na sekundę. PHP do czego innego się wybiera. Czemu w PHP nie pisze się gier na Windowsa? Czemu w C# nie napisano serwera Apache? Czemu Linux nie został napisany w Javie? I tak dalej. To tylko NARZĘDZIE, a artykuł zapewne miał za zadanie poznanie narzędzie na podstawie podobieństw i różnic.

    • Biznesowe zastosowanie Javy – chyba tylko dlatego, że szybko można coś w niej naskrobać, a w Bangladeszu łatwo o programistę.
      Wspominasz o maszynach obsługujących "miliony zapytań na sekundę" – Mam trochę do czynienia z dużymi maszynami zarówno biznesowymi jak i HPC – te miliony/s to jest nadal technogia sprzed 40 lat: mainframe, cobol, a krytyczne kawałki kodu pisze się w assemblerze (tyle że assembler manframe jest trochę inny) – mówię tu o na prawdę dużych instytucjach – NYSE, czołowe banki. A w przypadku midrange spod znaku 3liter to jeszcze RPG. Java na wielkich Powerach czy Exadatach nawet nie zbliża się do tych wartości, mimo, że konsumuje porównywalną moc, a ani procesory ani reszta architektury kulawe tam nie są.
      Oczywiście masz rację – Java jest w biznesie. Wszystkie nowinki się w niej implementuje. Ale na szczęście tak jak zaczyna się exodus producentów z Chin, tak też zaczyna się odejście od Javy – Oracle nie jest już tak przewidywalnym partnerem jak Sun, więc firmy szukają ucieczki. Pierwszy był Microsoft, który się na Javę wypiął jeszcze jak Sun dał mu po uszach za J++ i swoją implementację VM i zrobił C#. Nie dawno SAP, który jasno powiedział, że jakieś kawałki (nie pamiętam niestety jakie, chyba coś związanego z procesami i logiką biznesową) jego oprogramowania nie będą już javowe – wraca bodajże do Abapa.
      Trochę szkoda, że Google nie przegrał procesu o Dalvika – gdyby się udało, odeszliby od Javy i kto wie, może Objective C by wróciło do łask. BTW, za sprawą Appla to jest zdaje się jeden z 3 najpopularnijeszych języków programowania

    • Obj-C już wrócił do łask :). Apple ma jednak ogromną siłę przebicia, za co by się nie wzięli.

    • Objective-C w benchmarkach jest jakieś 30% wolniejszy od C, to tak samo jak Java. Nie wydaje mi się aby Objective-C był takim świetnym językiem. C# w zasadzie niewiele różni się od Javy, tyle że na Linuksie jest znacznie groszy.
      A system giełdowy Millenium zrobiono właśnie w Javie z dodatkiem C++, bo C# z Windowsami był za wolny :)

    • Niedawno była AMA na Wykopie z jakimś programistą ze Szwajcarii robiącym systemy do bardzo szybkich transakcji na giełdach (te tajemnicze "grzebienie"). I on używał Javy, do której pisał dodatki w Asm, żeby szybciej reagował program.
      Tam muszą być straszne czasy reakcji jak na wielozadaniowe systemy, ale jak widać da się i używają w tym Javy.

  9. "W przypadku aplikacji użytkowych taki spadek wydajności nawet nie jest zauważalny." aplikacje użytkowe / klienckie właśnie w Javie chodzą tak że można się pochlastać.

    • libreoffice nie jest napisany w javie, ba już chyba wywalili z niego wszystkie pluginy, które w niej były.

    • Zostało jeszcze trochę jak połączenia z bazą w Base itp. Ale generalnie po woli pozbywają się zależności od Javy.

    • @Bambus tak samo można powiedzieć o źle napisanych programach w C++ co zamulają kompa, albo walną jakimś errorem i wywalą się. Nieoptymalny i zamulający program można napisać w C++, .NET i tak dalej jak już wcześniej wspomniano.

    • Ba, w C++ o zamulający program o wiele łatwiej. Wystarczy "zapomnieć" lokalizacji wskaźnika i memory leak jak nic. Dodatkowo wszędobylskie wskaźniki, nawet w miejscach gdzie zwykła zmienna byłaby wystarczająca…

  10. Dwa antyprzukłady tezy, że Java nie jest powolna.
    1- Android vs iOS: który dział płynniej i daje wrażenie, ze działa gładko i jest responsywny. W JIT/JVM.Dalvik czy jak to zwać po prostu widać i czuć. Koniec. Urzadzonka z Androidem mogę mieć setki rdzeni i i terabajty ramu a i tak jest to charakterystyczne zacięcie, jak program musi być wystartowany ponownie. Tu liczy się ogólne wrażenie usera, a to jest na niekorzyść Javy.

    I przykład drugi – skrajnie inny – aplikacje enterprise (siedzę trochę w technologii IBM) tutaj może i język nie jest winny, winne są absurdalne wzorce projektowe (EJB, które swego (dawnego co prawda) czasu dla każdego wiersza z zapytania SQL produkowało obiekt z metodami) czy implementacja np garbage collectora zwlaniająca developerów z myślenia. W efekcie aplikacje od modelowania procesów biznesowych czy innych serwis-busów potrafią zabić maszynę miliard razy mocniejszą od kalkulatora który wysłał Apollo na księżyc! Ale znowu – ogólne wrażenie: masakra. A na koniec dnia liczy się nie to, czy JIT szybko odwróci macierz, ale to czy user końcowy będzie zadowolony. A kiedyś się połapią, że kupowanie maszyny za 1E6 $ do zadań ,które da się zaimplementować na liczydle to jest lekkie ładowanie w trąbę.

    • "Urzadzonka z Androidem mogę mieć setki rdzeni i i terabajty ramu a i tak jest to charakterystyczne zacięcie"
      bzdura, na moim SGSII nie ma żadnego "charakterystycznego zacięcia".
      Czasami przycina się mój stary chiński tablet. z tym że nie ma on nawet 500MHz.
      przez moje ręce przewinęło się parę różnych systemów mobilnych, łacznie z windows ce, więc mam jako takie pojęcie.

      BTW. mocożerne aplikacje na Antka są natywne a nie w Dalviku.

      Generalnie java ssie

    • Mam w łapkach 3 andki- Wildfire S, Galaxy ACE i Tab 8.9 LTE – wszystkie miewają zacięcia – zawsze przy przełączaniu pomiędzy aplikacjami. Ja na szczęście mam większe zacięcie do Androida. Wpp już dawno bym ukradł żonie jej przedpotopowego ajfona 3, który szybkością zjada na śniadanie moje zabawki :-( . Czekam na ICS na Tab'a może będzie lepiej, niestety LTE trochę poczeka.
      A to nie jest przypadkiem tak, że natywny kod woła się i tak z poziomu JNI, więc aplikacja i tak jest w Javie?
      Wracając do tematu ssania :-) – jeszcze jedno spostrzeżenie – imho Java spowodowała znaczne obniżenie poziomu programistów. Nadmiar dostępnych bibliotek, często wątpliwej jakośći powduje ,że programy w Javie często są po prostu bardzo kiepskie, a bardzo napięty release managment skutecznie wystudzi wszystkie próby poprawienia. Osobiście widziałem przypadek, kiedy programista w dużej firmie poszedł do PMa i powiedział , że może cośtam przepisać lepiej. PM powiedział: OK, ale build jest jutro. Koniec dyskusji, a produkt poprawi się na etapie patchy jak się wyłoży u klienta.
      Jako admin takiego "softu" dodam jeszcze, że mam ochotę strzelać do "developerów", którzy do loga przeznaczonego dla admina, wrzucają output z system.out.println(wyjątek) – po grzyba mi widzieć czasem tysiące linii co kogo wywołało , skoro ważne jest, że jakiś plik nie jest na miejscu, albo prawa dostępu się posypały?!
      Ssie. Święte słowa.

    • "A to nie jest przypadkiem tak, że natywny kod woła się i tak z poziomu JNI, więc aplikacja i tak jest w Javie? "
      Nie do końca. Bo nie ładuje się dużo klas i nie trzeba niczego kompilować JITem, a całą pracę wykonuje natywny kod. Tyle, że w C++ jest raczej mało aplikacji. Głównie gry.

      " imho Java spowodowała znaczne obniżenie poziomu programistów. "
      Sądzę, że nie ma to żadnego związku. To pogoń za pieniądzem. Liczy się ilość nie jakość. Gdyby kliencie się na to nie godzili to taka sytuacja nie miałaby miejsca. Do tego wydaje mi się, że jakość programów w językach kompilowanych do natywnego kodu mogłaby być znacznie gorsza, bo te zazwyczaj wymagają jeszcze więcej czasu, aby doprowadzić program do używalności.

    • Znowu brak czytania ze zrozumieniem. Z jakim ajfonem to porównuję?! Żal.
      Dla uproszczenia podsumuję specyfikację techniczną:
      iphone 3 – zegarek 412Mhz , 128MB RAM, data premiery 07/2008.
      Wildfire S: zegar: 600Mhz, RAM 512, premiera: 05/2011
      Galaxy ACE: zegar 800Mhz, RAM 384, premiera: 1 kwartał 2011.
      O Tabie 8.9 pisać chyba nie muszę…

    • Dalvik to nie to samo co JVM, to trochę inny rodzaj Javy, nieco inna zasada działania, tyle że ma zgodne API. Java ME działała całkiem wydajnie na starych słabych telefonach, Dalvikowi daleko jeszcze do tej wydajności.
      Objective-C tak bardzo nie odbiega od Javy i nie jest jakoś specjalnie wydajniejsza. Tutaj decyduje raczej konstrukcja systemu.
      Tak jak piszesz, w iOS liczy się co klika użytkownik, tak aby miał wrażenie że cały czas telefon go słucha. Ponoć w nowszych Androidach zachowanie jest bardziej podobne do iOS. Poza tym, takie opóźnienia to koszt JIT.

      Z drugiej strony, gdyby Google kazało pisać na Androida aplikacje tylko w C/C++ to ten system nie byłby popularny.

    • O Boże…

      iOS jest pisany na 5 urządzeń natomiast Android jest pisany na setki urządzeń. Poza tym menu w iOS ma najwyższy priorytet. Czyli nie ważne co się dzieje, przejścia mają być płynne. To porównanie było lekko z kosmosu :)

    • czyżby? Na koniec dnia i tak liczy się user experience :-). Bardzo czekam na ics, bo tam ponoć jest właśnie z responsywnością dużo lepiej. Niestety z moi sprzętami, jeszcze poczekam.
      I masz rację z tą fragmentacją. To jednocześnie i siła i słabość androida. Dyskusja stara jak apple i microsoft.

  11. "W internecie i nie tylko aż roi się od stwierdzeń typu "Java jest 20 razy wolniejsza od C++". "

    W życiu nie widziałem takiego stwierdzenia, a sam jestem z tych, którzy po Javie jeżdżą często i bezpodstawnie :) Gdyby Java była 20 razy wolniejsza, to nie byłoby Javy. Jeżeli jest wolniejsza to co najwyżej w przedziale (1,1.5>.

    Artykuł fajny szkoda tylko, że autor nie ma pojęcia o testach performance dla jeżyków :) Brakuje mi także przede wszystkim kodów źródłowych z obu języków i poleceń kompilacji.

    Czasu wykonania programu NIE MOŻNA mierzyć w czasie ralnym – to jest głupota. Sortowanie bąbelkowe wykonane kilka razy pod rząd w C++ posiada czasy z rozrzutem 0.5sekundy. W Javie nie testowałem, ale tam zapewne sprawa wygląda podobnie. Czasy performance mierzymy w czasie procesora, czyli faktycznej liczbie tyknięć procesora, które musiały zostać wykonane aby program działał.

    Sam ostatnio przeprowadzałem testy pewnego algorytmu na szybko, właśnie z takimi czasami jakich używał autor. Puszczałem algorytm na 1000 danych 1000 razy. Rozbieżności względem czasów 13s – 20s były nawet 2 sekundy.

    Jeżeli artykuł miał udowodnić, że Java nie jest 20 razy wolniejsza, to udowodnił. Bo nie jest ponad wszelką wątpliwość. Ale czasy są zbyt niedokładne aby ocenić czy jest szybszy czy wolniejszy, i o ile.

    • A ja dość często spotykam, nawet u mnie na uczelni wisi jeszcze stara kartka porównująca Javę do C++ gdzie pierwszym punktem jest właśnie te stwierdzenie. Kody tam gdzieś w koementarzach są, one nie są istotne, bo to jak napisałem nie jest żaden dokładny benchmark.

      Rozrzut zależy od systemu, nie języka, czy użytej technologii – ile jest procesów w tle i kiedy zachce im się coś robić. Na systemie jednozadaniowym czasy te byłyby stałe, niemal bez żadnych rozrzutów. Testy powtarzałem kilka razy, rozrzuty były niewielkie, ile razy to jeszcze muszę napisać…. Czasy nie były realne, tylko "czas spędzony przez proces w procesorze".

      I nie da się jednoznacznie określić "ile wolniejsza" – z jednymi rzeczami radzi sobie lepiej, z innymi gorzej, nigdy nie ma uniwersalnego "naj".

    • A co Ciebie interesuje z JAVY?

      PS. Czemu nie pojawiasz się na spotkaniach OSWorld? Tam ostatnio gadaliśmy o javie.

  12. Tak się zastanawiam.. czy jest to konieczne, żeby Java tłumaczyła kod JVM na natywny za każdym razem? Przecież od momentu instalacji programu do momentu jego aktualizacji kod programu się nie zmienia. Nie dałoby rady zrobić czegoś takiego, że pierwszy raz kiedy uruchamiamy program to wtedy jest on kompilowany do natywnego przy użyciu JVM a przy kolejnych uruchomieniach korzystamy z natywnego? No i oczywiście jakieś trzymanie sum kontrolnych, żeby JVM był w stanie się zorientować, że bytecode się zmienił

  13. Jaki głupi test i w dodatku nie sprawiedliwy. Autor zapomniał, że programy w C/C++ kompiluje się RAZ! a JAVA … uhuuueeeee … sami wiecie.

  14. […] Jeśli chodzi o wady Javy, to najczęściej wspomina się o dwóch aspektach. Po pierwsze, do uruchomienia napisanego w niej programu, należy mieć zainstalowaną tzw. wirtualną maszynę (JVM). Wielokrotnie mogliście pewnie zauważyć wyskakujące powiadomienie o konieczności aktualizacji oprogramowania firmy Oracle. Działo się tak w momencie, gdy chcieliście uruchomić coś napisanego w najnowszej postaci języka, a zainstalowaną mieliście już nieaktualną wersję wirtualnej maszyny. Z racji konieczności posiadania JVM w systemie, powszechnie panuje opinia, że napisane w Javie aplikacje działają o wiele wolniej niż np. te utworzone w C++. Powstało wiele testów na ten temat, a w sieci znajdziecie pewnie dziesiątki ciekawych wątków dyskusyjnych. Oczywiście brak mi eksperckiej wiedzy w tej kwestii, dlatego jeśli chcecie zgłębić temat polecam poczytać chociażby: https://osworld.pl/czy-java-faktycznie-jest-taka-wolna/ […]

ZOSTAW ODPOWIEDŹ

Proszę wpisać swój komentarz!
Proszę podać swoje imię tutaj