Autor Wątek: Java nie optymalna? (było: Co myslicie o Java jako platformie do pisania gier?)  (Przeczytany 8251 razy)

Offline zenek_tm

  • Użytkownik

# Styczeń 16, 2006, 23:39:02
Helo helo :) i do sedna.

Cytuj
Zgadza się. Tylko, że klasa problemów do których GC się przydaje jest bardzo wąska (grafy i... może jeszcze grafy). W każdym innym przypadku GC albo jest równie skuteczny jak zliczanie referencji albo wręcz przeszkadza. Ot jeśli chcesz zamknąć gniazdko sieciowe w przypadku wystąpienia wyjątku - C++ z RAII zrobi to automatycznie (destruktor) a z GC musisz to dobić mniej lub bardziej ręcznie (,,Dispose pattern'' w Javie, using w C#).

Akurat, zeby zamknac gnizado sieciowe, wywolujesz gniazdo.close(); i zapominasz. Zreszta operacje na sockecie zwracaja wyjatki, ktore trzeba przechwycic. Nawet jezeli nie chcesz obslugiwac danego wyjatku, to i tak dajesz try {} finally { socket.close(); } i zapominasz o problemie. I co to jest ten "Dispose pattern"?

Cytuj
No i jeszcze .03 PLN nt. JIT i kompilacji w ogóle. JIT ma ogromny potencjał. Można bowiem wyobrazić sobie, że kompilacja jest optymalizowana wynikami konkretnych uruchomień programu (wyłapywane są najczęściej używane ścieżki w rzeczywistym użyciu) - ot taki doskonały profiler. Ale
a) jeszcze o takich zabawkach nie słychać,
Zapomniales rowniez o kompilacji pod dany procesor (uzycie jezeli jest dostepne i ma sens SSE2 i SSE zamiast FPU czy MMX zamiast czegos tam :) ). Aczkolwiek zarowno .NET jak i JVM SUNa juz to robia. Moze to dawac spore roznice w czasach wykonania w porownaniu nawet do ubostwianego przez wielu C++.

Offline Mr. Spam

  • Miłośnik przetworów mięsnych

Offline Kamil Trzciński

  • Użytkownik

# Styczeń 17, 2006, 00:00:38
Akurat, zeby zamknac gnizado sieciowe, wywolujesz gniazdo.close(); i zapominasz. Zreszta operacje na sockecie zwracaja wyjatki, ktore trzeba przechwycic. Nawet jezeli nie chcesz obslugiwac danego wyjatku, to i tak dajesz try {} finally { socket.close(); } i zapominasz o problemie. I co to jest ten "Dispose pattern"?

Taki schemat własnie realizuje "using" w C#, a ten Dispose pattern jest to specjalny interfejs, ktory jest przeladowany w klasie, a metoda 'Dispose' tego interfejsu sluzy do 'recznego' niszczenia obiektu, cos jak socket.close().

bies

  • Gość
# Styczeń 17, 2006, 00:03:38
Cytat: zenek_tm
Akurat, zeby zamknac gnizado sieciowe, wywolujesz gniazdo.close(); i zapominasz. Zreszta operacje na sockecie zwracaja wyjatki, ktore trzeba przechwycic. Nawet jezeli nie chcesz obslugiwac danego wyjatku, to i tak dajesz try {} finally { socket.close(); } i zapominasz o problemie. I co to jest ten "Dispose pattern"?
Link do poczytania: http://blogs.msdn.com/hsutter/archive/2004/07/31/203137.aspx
Trick polega na tym, że w dobrze zaprojektowanym programie w C++ try {...} catch (...) musisz używać bardzo rzadko (główna pętla wątku (programu), punkty krańcowe bibliotek, granice podsystemów). W Javie tak nie możesz, bo każdy lokalny rzadki zasób musi być zwolniony ręcznie.

Cytat: zenek_tm
Zapomniales rowniez o kompilacji pod dany procesor (uzycie jezeli jest dostepne i ma sens SSE2 i SSE zamiast FPU czy MMX zamiast czegos tam :) ). Aczkolwiek zarowno .NET jak i JVM SUNa juz to robia. Moze to dawac spore roznice w czasach wykonania w porownaniu nawet do ubostwianego przez wielu C++.
Nie wiem czy wiesz, ale ja mam system i większość programów skompilowane pod mój procesor. I nie jest to system napisany w Javie. ;D

Offline Kamil Trzciński

  • Użytkownik

# Styczeń 17, 2006, 00:20:45
bies, ale ile ta kompilacja trwala :) od tego zacznijmy, a kod jest JITowany mozna powiedziec w 'locie' , oczywiscie jakosc takiej przerobki jest znosna, np. inline'owanie nie jest tak rozbudowane jak w C++ (ogolnie optymilzacje kodu), w sumie mogli by dodac jakas opcje, aby mozna bylo sobie wlaczyc porzadne inline'owanie :D, ale i tak ile JITer robi optymilizacji w tak krotkim czasie :)
« Ostatnia zmiana: Styczeń 17, 2006, 00:23:57 wysłana przez ayufan »

bies

  • Gość
# Styczeń 17, 2006, 01:11:09
Ayufan: a nie mam pojęcia, przecież nie robiłem tego sam - od tego są buildery dystrybucji. ;D (Nie, nie rozmawiajmy o Gentoo).

Poza tym, ja się zgadzam, że JITC to duże pole do popisu dla języków klasy Javy. Również dlatego, że języki te zadowalają się prostszą konstrukcją (wyobraź sobie JITC dla szablonów C++ ;D ). Mimo wszystko, wraz z lepszymi optymalizacjami czas takiej kompilacji będzie rósł. I jak sądzę zarówno Sun jak i MS wybrały drogę w kierunku większej integracji VM z systemem (tak aby JITC lepiej wykorzystywał idle time procesora).

Niemniej jednak uważam, że tak drastyczne uproszczenie języka jest zbyt dużą ceną. Nie wnikając już czy chodziło o względy techniczne (obiekty automatyczne i destruktory razem z GC) czy o marketingowe (przeciążanie operatorów i wielodziedziczenie jest ,,takie trudne do zrozumienia'').

Aha, piszę w Javie na co dzień i najbardziej podobają mi się anonimowe klasy. :D

Offline zenek_tm

  • Użytkownik

# Styczeń 17, 2006, 08:18:47
Cytuj
Poza tym, ja się zgadzam, że JITC to duże pole do popisu dla języków klasy Javy. Również dlatego, że języki te zadowalają się prostszą konstrukcją (wyobraź sobie JITC dla szablonów C++ Grin ). Mimo wszystko, wraz z lepszymi optymalizacjami czas takiej kompilacji będzie rósł. I jak sądzę zarówno Sun jak i MS wybrały drogę w kierunku większej integracji VM z systemem (tak aby JITC lepiej wykorzystywał idle time procesora).
Zarowno Java jak i C# maja juz od pewnego czasu szablony i jakos nie wplynelo to zbytnio na czasy JITowania.

bies

  • Gość
# Styczeń 17, 2006, 13:18:24
Cytat: zenek_tm
Zarowno Java jak i C# maja juz od pewnego czasu szablony i jakos nie wplynelo to zbytnio na czasy JITowania.
Albo nie znasz szablonów C++ albo Javy (C#). Szablony w Javie to tylko ładne opakowanie (lukier syntaktyczny) na rzutowanie. Bardziej przypominają makra działające na void * (złożonością, funkcjonalnie dodają do języka lepszy system typów, głównie w kolekcjach). W C++ szablony to pełnowartościowy język (meta)programowania.

Trochę inaczej ma się sprawa w C#. Tam, zważywszy na to, że jest to młody język i nie używany naprawdę na serio, MS mógł wprowadzić zmianę do VM i zapisać informacje o typie szablonu. Z resztą, poczytaj sobie. [1]

Aha, należy brać poprawkę, że jest to wywiad z jednym z twórców C#. Bardzo ciekawy jest np. wątek o tym, że C++ ma słabe typowanie szablonów (w przeciwieństwie do C#). Po czym autor stwierdza, że system typów w szablonach C++ jest tak skomplikowany i ma tak duże możliwości, że zdecydowali się na coś łatwiejszego. Aha, IMO facet ma średnią wiedzę nt. szablonów C++. Np. warunki brzegowe (constraints) dla typów szablonów tworzy się dość łatwo. [2]

W każdym bądź razie ani Java ani C# nie zbliżają się nawet do możliwości szablonów C++.

[1] http://www.artima.com/intv/generics.html
[2] http://www.research.att.com/~bs/bs_faq2.html#constraints
« Ostatnia zmiana: Styczeń 17, 2006, 14:10:00 wysłana przez bies »

Offline Xion

  • Moderator
    • xion.log

# Styczeń 20, 2006, 13:09:09
bies: Coś w tym słabym typowaniu szablonów w C++ musi być, skoro wedle niedawno artykułu artykułu Stroustropa pewna forma constraintsów jest rozważana jako ważne uzupełnienie w C++0x. Oczywiście chodzi raczej o typowanie typów niż predykaty podobne do tych podanych przez ciebie w [2].

bies

  • Gość
# Styczeń 20, 2006, 14:57:35
Xion, masz na myśli artykuł ,,A Brief Look at C++0x'' [1]? A jeśli tak to czy chodzi Ci o konstrukcję:template<class T> using Vec = vector<T,My_alloc<T>>;Ona nie zwiększa bezpieczeństwa typów, dodaje tylko alias szablonowy. Tak jak typedef dodaje alias dla typów nieszablonowych. Z resztą powszechnie nazywa się taką konstrukcję właśnie ,,template typedef'' ale ze względów praktycznych (kompilatory C++ i tak mają mocno przechlapane, nie potrzeba dokładać im dodatkowej pracy w rozróżnianiu czy ten typedef dotyczy szablonów czy nie) zdecydowano się na using.

No chyba, że piszesz o jakimś inny artykule. Jeśli tak podaj link, chętnie przeczytam.

[1] http://www.artima.com/cppsource/cpp0x.html