Szybka Java - real time?

Zastanawiam się, obecnie na ile szybka jest Java. Czy działa tak wolno, że w zastosowaniach RT, gdzie szybkość jest ważna ją stanowczo wyklucza, czy może różnica w szybkości między nią a np. C++ jest do przyjęcia?

Znalazłem ciekawy artykuł w SDJ aż z 2005r.. Jest dosyć ciekawy i rozwiązuje bodajże największą bolączkę, Javy - odśmiecanie, które to potrafi spowolnić program w najmniej oczekiwanym momencie.

Link do kopii artykułu: http://software.com.pl/java-czasu-rzeczywistego-zmniejszanie-dystansu-do-cc/

Sam artykuł bardzo ciekawy, ale w Javie od 2005 do 2011, musiało coś się zmienić na plus. Nie mogłem jednak znaleźć na ten temat informacji aktualniejszych. Może coś wiecie na temat Javy w RT i potraficie odp. na pierwsze pytanie?

W RT nie tyle chodzi o szybkosc, o ile o zagwarantowanie z gory okreslonych czasow przeprocesowania wydarzen / rozkazow. W zwyklej Javie np problemem jest GC, poniewaz od czasu do czasu jest to operacja 'stop the world', w czasie ktorej zadne gwarancje co do czasu nie beda spelnione.

Platforma czasu rzeczywistego to taka, w której każdą operację można ograniczyć z góry jakimś tam wzorem na czas, np lista.dodaj(element) to O(lista.długość). W normalnej Javie nie ma takiej gwarancji, bo odśmiecanie może nastąpić w dowolnym momencie i w sposób niedeterministyczny wydłużać czas reakcji. Poza tym dochodzą priorytety wątków itp opisane na Wiki wszystko. Wpisz w Google: real time java - powinno wyskoczyć mnóstwo przydatnych artykułów do poczytania.

Jakość optymalizacji w JVM jest już dość dobra: http://shootout.alioth.debian.org/u64q/benchmark.php?test=all&lang=all Jak widać większość języków ma znośną wydajność, tzn ich kompilatory mają już dobrej jakości optymalizacje. Wyjątkami są np PHP, Ruby czy Python (wszystkie interpretowane), które przy pisaniu bez użycia bibliotek napisanych w C, są setki razy wolniejsze od C.

Ludzie dalej szerzą pogląd, by od Javy stronić, no chyba, że piszemy aplikacje bazodanowe, księgowe etc. Przeglądając wiele wypowiedzi specjalistów natomiast sprawa wygląda trochę inaczej, twierdzą, że obecnie Java jest b. szybka i wiele nie ustępuje tutaj C++, czy bliższemu C#.

Ciekawe rozwiązanie z GB jest w tym artykule.

Jeśli natomiast chodzi o pisanie gier (które procka, jak i RAMu potrzebują,a jeszcze więcej k.graf. ale chyba tutaj nie w tym rzecz?) to w C++ jak najbardziej, widywałem niezłe produkcje w C# pisane, natomiast w Javie rzadko widuję gry napisane, ale się zdarzają. Myślę, że jeżeli chodzi o szybkość to napisanie nie wymagającej mocno gry w 2D w javie jest możliwe i całkiem znośne. Ale trochę lepsze w 3D zdecydowanie odpadają. Chociaż Minecraft jest świetny i w Javie pisany, wymagania ma małe (fakt, że grafika jest... specyficzna), to ciekawe o ile procent szybciej by chodził napisany w C++ lub C#

Cóż to za produkcje w C#?

Problem z Javą czy C# jest taki sam jak w systemach real-time - lag spowodowany na przykład odśmiecaczem to lag w grze. W grach FPS lag na kilkadziesiąt milisekund może być zabójczy (a już na pewno w produkcjach typu Counter Strike). W Javie czy C# można za to spokojnie pisać gry, które nie wymagają natychmiastowej reakcji na zdarzenia i lag nawet sekundowy co jakiś czas jest akceptowalny.

Można też po prostu wyłączyć GC i odpalać go ręcznie w momentach, w których można sobie na to pozwolić.

Co do gier w Javie, to jak się nie mylę któraś rajdówka komercyjna (o ile mnie pamięć nie myli to Xpand Rally Extreme) była w Javie. Był plik .exe, ale oprócz tego masa .jar

Razi91 napisał(a)

Można też po prostu wyłączyć GC i odpalać go ręcznie w momentach, w których można sobie na to pozwolić.

Tak tak, wylaczyc GC <lol>. I recznie odpalac, <lol2>.

Tak sie sklada ze GC nie mozna wylaczyc. Teoretycznie reczne odpalanie nie wchodzi w gre, poniewaz System.gc() tylko daje znac ze program chcialby aby wykonane zostalo odsmiecanie. JVM wcale nie musi go wykonac jesli uwaza inaczej (hint: JVM Sun / Oracle jednak wykona odsmiecanie, ale mozna dac -XX:-DisableExplicitGC (http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html).
Poprogramuj troche jeszcze, duzo poczytaj, pozniej sie wypowiadaj.
Co do mnostwa 'jarow' to masz na mysli gry na komorke? Chyba nie o to chodzilo przedmowcom ;d

jambalaya napisał(a)

Razi91 napisał(a)

Można też po prostu wyłączyć GC i odpalać go ręcznie w momentach, w których można sobie na to pozwolić.

Tak tak, wylaczyc GC <lol>. I recznie odpalac, <lol2>.

Tak sie sklada ze GC nie mozna wylaczyc. Teoretycznie reczne odpalanie nie wchodzi w gre, poniewaz System.gc() tylko daje znac ze program chcialby aby wykonane zostalo odsmiecanie. JVM wcale nie musi go wykonac jesli uwaza inaczej (hint: JVM Sun / Oracle jednak wykona odsmiecanie, ale mozna dac -XX:-DisableExplicitGC (http://www.oracle.com/technetwork/java/javase/tech/vmoptions-jsp-140102.html).
Poprogramuj troche jeszcze, duzo poczytaj, pozniej sie wypowiadaj.
Co do mnostwa 'jarow' to masz na mysli gry na komorke? Chyba nie o to chodzilo przedmowcom ;d

Z wyłączaniem GC w Javie się nie bawiłem. Wkurzał mnie jakiś czas, ale miałem lukę w kilku metodach uruchamiających nowe wątki (które później nie były kończone w żaden sposób, bo gubiła się referencja do nich, a jako zatrzymany wątek istniał sobie dalej ze swoim ScriptEnginem po wykonaniu skryptu), stąd masakrycznie długi czas GC, który zawieszał program na pół sekundy prawie.

A co do tej gry, to to jest na PC z użyciem silnika fizycznego ODE.
http://www.java-gaming.org/index.php?topic=6567.0
jary to też biblioteki w Javie, nie tylko te wykonywalne (tzn. te z przygotowanym manifestem i ustawioną jedną klasą jako główną)

Problem z Javą czy C# jest taki sam jak w systemach real-time - lag spowodowany na przykład odśmiecaczem to lag w grze. W grach FPS lag na kilkadziesiąt milisekund może być zabójczy (a już na pewno w produkcjach typu Counter Strike). W Javie czy C# można za to spokojnie pisać gry, które nie wymagają natychmiastowej reakcji na zdarzenia i lag nawet sekundowy co jakiś czas jest akceptowalny.
Jak dobrze grę napiszesz, to będą niezauważalne i w fps'ie...

@Olagamoto Wcale nie trzeba robić poolowania obiektów... Można JRE odpalić w server mode + escape analysis
Na linuksie i tak zazwyczaj jak jest java, to jest to jdk.
Na windowsie wystarczy w /bin/server/ wkleić serwerowe jvm.dll - instalator twojej gry może to zrobić
Na macu nie wiem, ale się jeszcze dowiem co i jak

To jest wtedy szybsze niż javowy client mode i C#.. dużo szybsze...

Inna sprawa, że srsly to renderowanie zapieprza najwięcej zasobów, a renderować i tak nikt nie renderuje w czystej Javie - nawet standardowa biblioteka Javy używa natywnych rozwiązań- więc gra 2d w czystej Javie będzie szybka, bo Java2D samo z siebie używa d3d/opengl do renderowania.
Gra 3d z użyciem jogl/lwjgl też powinna być szybka...
Logika gry może iść w innym wątku niż renderowanie...

Wibowit napisał(a)

Cóż to za produkcje w C#?
Pewnie Magicka :P

Co do mnostwa 'jarow' to masz na mysli gry na komorke? Chyba nie o to chodzilo przedmowcom ;d
Przecież napisał, że tam było exe.