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.
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:
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.
Ja uważam że java nie jest wolna tylko pamięciożerna (zasobożerna)
I dobrze. RAM jest tani. Programiści już nie.
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?
RAM na serwerze często nie jest tani, bo często jest tam potrzebny ECC, a ten jest drogi w cholerę.
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.
Dlatego JAVE wykorzystuje się na serwerach do tworzenia dużych systemów (systemy bankowe, serwisy aukcyjne i tak dalej) a nie na głupie programy na Windowsa.
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ć.
Tak, a potem system grzebie ciągle po swapie, a IO dysku skutecznie zamula i tak już powolną Javę.
Możesz sobie podczas odpalania wymusić górne granice.
Oczywiście, że możesz i nie tylko to ustalić. Java daje naprawdę duże możliwości a w połączeniiu z serwerem aplikacyjnym jeszcze większe.
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!
No. Android najlepszym przykładem…
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.
korekta: „infantylne”
Ja uważam że java nie tylko jest wolna, ale także pamięciożerna (zasobożerna)
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. :)
Ale Python zabiera kilka MB ramu, a z GUI kilkanaście.
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.
I pomimo zużywania gigabajtów pamięci wciąż szybka nie jest. Jednym słowem: FAIL.
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.
Ale długo startuje JVM. Ale zanim program się uruchomi – musi uruchomić swoje środowisko pracy.
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 :)
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ć.
TAK, Java faktycznie jest taka wolna.
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.
Popatrz, a i tak to "gŁupie" PHP jest szybsze od Javy…
Pewnie nie widziałeś nigdy ani działającego PHP, ani Javy :)
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.
Co do APC to się zgodzę. Nie działa zawsze stabilnie i powoduje problemy przy dużym ruchu. Testowałem również xcache i eaccelerator i wygląda to podobnie.
Java nie jest wolna :)
I nie komentujcie wypowiedzi o_O, bo to kretyn i liczy na trolling.
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.
Coraz trudniej? Ja już nie mam żadnej od jakiegoś czasu (ostatni upadł ww. JD).
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.
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ł.
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.
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.
Nie trzeba pracować w Szwajcarii. W Polsce też takie systemy kodujemy i utrzymujemy ;-) Oczywiście Java :)
"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 i PHPStorm działają bardzo dobrze.
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…
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
Takie generalnie to sobie możesz w dupie wsadzić, bo ja mogę napisać, że generalnie to Twoja matka ssie.
Plusy za tą wypowiedź? Fani javy myślą chyba dupą zamiast głowy…
A ty swoją czapeczką z aluminium, paranoiku.
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.
Następny fachowiec co porównuje niskobudżetowe telefony ze starym Androidem do iPhone'a. Żal.
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.
"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".
> I nie da się jednoznacznie określić "ile wolniejsza" – z jednymi rzeczami radzi sobie lepiej, z innymi gorzej, nigdy nie ma uniwersalnego "naj".
Pod tym względem najlepszy wydaje się http://shootout.alioth.debian.org/
Fajny artykulik :) Też wydawało mi się, że JAVA nie jest wolna tylko programiści nie wiedzą jak z niej korzystać ;P
Masz rację, wydawało ci się.
Mam nadzieję, że to pierwszy z serii artykułów na temat Javy ?
A co Ciebie interesuje z JAVY?
PS. Czemu nie pojawiasz się na spotkaniach OSWorld? Tam ostatnio gadaliśmy o javie.
https://osworld.pl/o-nas/spotkania/
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ł
O ile na PC teoretycznie miałoby to sens, o tyle gorzej z systemami wbudowanymi.
Jaki głupi test i w dodatku nie sprawiedliwy. Autor zapomniał, że programy w C/C++ kompiluje się RAZ! a JAVA … uhuuueeeee … sami wiecie.
[…] 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/ […]