Szybka Java - real time?

Odpowiedz Nowy wątek
2011-05-12 17:31

Rejestracja: 11 lat temu

Ostatnio: 4 lata temu

0

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-c[...]-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?


C++ to wyjątkowy język - wysokopoziomowy z niskopoziomowymi mechanizmami, którymi można rozwalić w drobny mak te wysokopoziomowe.

Pozostało 580 znaków

ucilala
2011-05-12 17:40
ucilala
0

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.

Pozostało 580 znaków

2011-05-12 17:44

Rejestracja: 15 lat temu

Ostatnio: 34 sekundy temu

0

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[...]ark.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.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.

Pozostało 580 znaków

2011-05-12 18:06

Rejestracja: 11 lat temu

Ostatnio: 4 lata temu

0

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 wyjątkowy język - wysokopoziomowy z niskopoziomowymi mechanizmami, którymi można rozwalić w drobny mak te wysokopoziomowe.

Pozostało 580 znaków

2011-05-12 18:11

Rejestracja: 15 lat temu

Ostatnio: 34 sekundy temu

0

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.


"Programs must be written for people to read, and only incidentally for machines to execute." - Abelson & Sussman, SICP, preface to the first edition
"Ci, co najbardziej pragną planować życie społeczne, gdyby im na to pozwolić, staliby się w najwyższym stopniu niebezpieczni i nietolerancyjni wobec planów życiowych innych ludzi. Często, tchnącego dobrocią i oddanego jakiejś sprawie idealistę, dzieli od fanatyka tylko mały krok."
Demokracja jest fajna, dopóki wygrywa twoja ulubiona partia.
Można też tak pisać gry, żeby szansa na uruchomienie odśmiecania w nieoczekiwanym momencie była minimalna lub żadna. Pierwszy przypadek, to przydzielenie całej potrzebnej pamięci i powtórne używanie obiektów (całkowity brak dealokacji), drugi - to zgrupowanie alokacji i potencjalnych dealokacji w osobnym managerze połączone z informowaniem gc o możliwości odśmiecania zanim zostanie to wymuszone warunkami, które muszą wyzwolić odśmiecanie. - Olamagato 2011-05-13 12:47

Pozostało 580 znaków

2011-05-13 23:07

Rejestracja: 9 lat temu

Ostatnio: 5 lat temu

0

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

Pozostało 580 znaków

jambalaya
2011-05-13 23:15
jambalaya
0
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/technet[...]ech/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

Pozostało 580 znaków

2011-05-14 00:31

Rejestracja: 9 lat temu

Ostatnio: 5 lat temu

0
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/technet[...]ech/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ą)

Pozostało 580 znaków

2011-05-14 00:32

Rejestracja: 11 lat temu

Ostatnio: 3 tygodnie temu

0

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.

edytowany 2x, ostatnio: Kerai, 2011-05-14 00:32

Pozostało 580 znaków

Odpowiedz

1 użytkowników online, w tym zalogowanych: 0, gości: 1, botów: 0