Autor Wątek: Kilka pytań dotyczących javy  (Przeczytany 9755 razy)

Offline Avaj

  • Użytkownik

# Wrzesień 02, 2010, 20:32:48
Że projekty studenckie w C++ są słabe to nie masz się co dziwić. U mnie na studiach cały C++ opierał się na tym, że 2 wykłady o STLu i przeciążaniu funkcji mieliśmy ;]

Offline Mr. Spam

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

Offline Kos

  • Użytkownik
    • kos.gd

# Wrzesień 02, 2010, 21:03:00
A u nas był ze szczegółami, podstawowe zastosowania szablonów wliczając (a wykładowca mówił że już powoli przerabia slajdy pod C++0x) :). Guru nie powstanie, ale przekazano wystarczająco dużo wiedzy do "normalnego" programowania.

(żeby nie było tak kolorowo - totalnie u mnie olano narzędzia :) zero słów na temat współczesnych IDE, systemów budowania, nawet "szczegółów kompilatora" typu include path; z plusów: obsługa valgrinda (yeah), gdb (z konsoli, yeah) i makefile (retro! yeaah :)).
« Ostatnia zmiana: Wrzesień 02, 2010, 21:05:12 wysłana przez Kos »

Offline JCoder

  • Użytkownik

# Wrzesień 02, 2010, 23:11:50
Cytuj
Że projekty studenckie w C++ są słabe to nie masz się co dziwić.

Zobacz, jaka jest typowo kolejność nauki języka C++, a jaka Javy. W C++ ludzie o wskaźnikach, new, delete, rzutowaniu, tablicach itp. dowiadują się stosunkowo wcześnie. Właściwie to nawet często jest to realizowane w ramach kursu C. Dosyć wcześnie ludzie dostają takie tematy do zrobienia jak zaimplementowanie listy jednokierunkowej, czy drzewa. Czyli uczą się metodą bottom-up. W pewnym momencie załapują, że w sumie mogą tak napisać teoretycznie każdy program, i zatrzymują się na tym poziomie, przenosząc poznane techniki do dużych projektów. Wychodzą z tego maszkarki, w których wszystko zależy od wszystkiego a wskaźnik pogania wskaźnik. O mechanizmach, które pozwalają pisać w sposób bezpieczniejszy (STL, Boost, wzorce projektowe) dowiadują się zwykle znacznie później. I wielu uważa to za nudy.

Z kolei w Javie jest dokładnie na odwrót. Ludzie najpierw poznają jak zrobić jakiś program z użyciem biblioteki standardowej, a dopiero później uczeni są rzeczy, w których potencjalnie mogą sobie narobić problemów tj. refleksji, przeciążania equals, wątków, JNI, pisania własnych kontenerów itp.

Inna rzecz, że nieprawdą jest, jakoby optymalny zespół to był taki, który składa się z samych guru programistów. Taki zespół pracuje niewiele lepiej niż zespół składający się z jednego, dwóch świetnych programistów + kilku przeciętnych, za to znacznie tańszych. Pilnowanie tych przeciętnych, żeby nie narobili w projekcie jakiejś poważnej biedy właśnie powinno spadać w dużej części na język / narzędzia, które zrobią to za darmo. Ktoś chce użyć pola statycznego aby ułatwić sobie dostęp do czegośtam (w środowisku wielowątkowym) - a tu Zonk, w języku nie ma pól statycznych ;) Ktoś chce sobie zrobić własny wątek, a tu bach po łapach, nie wkomituje kodu - pakiet obsługujący wątki jest zbanowany. Jeszcze inna sprawa, że zespół składający się ze zbyt wielu guru programistów może tkwić w miejscu, bo każdy będzie uważał że jego "projekt" jest jedyny słuszny...

Offline Dab

  • Redaktor
    • blog

# Wrzesień 02, 2010, 23:30:44
Cytuj
Ludzie najpierw poznają jak zrobić jakiś program z użyciem biblioteki standardowej, a dopiero później uczeni są rzeczy, w których potencjalnie mogą sobie narobić problemów tj. refleksji, przeciążania equals, wątków, JNI, pisania własnych kontenerów itp.

Tak -- a potem wyrastają "koderzy" dla których lista i wektor to jeden pies. "Przecież przejście po jednym i drugim to O(n)!"

Cytuj
O mechanizmach, które pozwalają pisać w sposób bezpieczniejszy (STL, Boost, wzorce projektowe)

Ostatnio integrowałem język skryptowy Lua ze swoim silnikiem. Postanowiłem spróbować z gotowym wrapperem (Luabind). Jednak kiedy zobaczyłem, że do użycia go potrzeba 1500 (PÓŁTORA TYSIĄCA) nagłówków Boosta to podziękowałem -- zamierzony efekt osiągnąłem w... 400 linijkach kodu.

Dalej nie rozumiesz różnicy między silnikiem/grą a "aplikacją biznesową". W zasadzie gry to jeden z niewielu rodzajów aplikacji które przy dużym skomplikowaniu logiki muszą jednocześnie być bardzo szybkie. Użycie STL, Boosta, wzorców projektowych, enkapsulacji, stutuacji doprowadza do tego że 95% kodu to tzw. "glue code" który nic tak naprawdę nie robi. A na to w grach nie ma po prostu czasu.

Cytuj
Inna rzecz, że nieprawdą jest, jakoby optymalny zespół to był taki, który składa się z samych guru programistów.

To jest oczywiste, ale czy ktoś kto liznął szablony i dziedziczenie to od razu guru?
« Ostatnia zmiana: Wrzesień 02, 2010, 23:34:12 wysłana przez Dab »

Offline Avaj

  • Użytkownik

# Wrzesień 02, 2010, 23:43:43
@Dab: jak używasz STL/Boosta itp. ot tak to wiadomo, że ten kod będzie nieprzydatny. Ale np. lepiej wziąć gotowca, który na pewno działa w ciężkich warunkach niż tracić czas na pisanie własnej implementacji. A wzorce projektowe i enkapsulacja nic nie kosztują, a pomagają ogarnąć kod.

Offline JCoder

  • Użytkownik

# Wrzesień 02, 2010, 23:51:48
Cytuj
Użycie STL, Boosta, wzorców projektowych, enkapsulacji, stutuacji doprowadza do tego że 95% kodu to tzw. "glue code" który nic tak naprawdę nie robi.

Coś w tym jest. Na pewno trzeba uważać, aby nie przesadzić z poziomem abstrakcji.
Z drugiej strony i tak najwięcej roboty ma sam silnik graficzny + fizyka, a wyższe warstwy już nie muszą być jakieś bardzo szybkie, bo liczba obiektów na których pracują jest znacznie mniejsza (LUA jest znacznie powolniejsza od wszelkich Javopodobnych wynalazków, a jednak jej używasz).
Sam fakt stosowania gotowego silnika grafiki / fizyki to już jest pewien rodzaj enkapsulacji ;)
« Ostatnia zmiana: Wrzesień 02, 2010, 23:53:31 wysłana przez JCoder »

Offline Dab

  • Redaktor
    • blog

# Wrzesień 03, 2010, 00:01:33
Cytuj
Z drugiej strony i tak najwięcej roboty ma sam silnik graficzny + fizyka, a wyższe warstwy już nie muszą być jakieś bardzo szybkie, bo liczba obiektów na których pracują jest znacznie mniejsza.

No widzisz. Problem w tym że wyższe warstwy też mają co do roboty. Logika/mechanika gry to zazwyczaj bardzo pokaźny kawałek kodu, a czy pracuje na mniejszej ilości obiektów? Nie powiedziałbym, to renderer może sobie wyciąć wszystko czego nie widać -- logika zasadniczo musi przetwarzać wszystko (a przynajmniej sprawiać takie wrażenie). Dodatkowo weź pod uwagę że logika musi uwzględniać interakcje między obiektami, czego renderer zasadniczo nie robi (no, chyba że doczekamy się RTGI).

Na wszystko jest miejsce i czas. W pracy (aplikacje iPhonowe) mogę sobie pozwolić na parę dodatkowych wywołań żeby mieć np. kilka kontrolerów pod wspólnym interfejsem. W porównaniu do czasu oczekiwania na dane z sieci te kilka wywołań więcej jest nieodczuwalne -- zresztą sam język i framework są dość ciężkie. Ale gry to inna bajka. Tutaj na "virtual void Draw()" daleko nie zajedziesz :)

Cytuj
(LUA jest znacznie powolniejsza od wszelkich Javopodobnych wynalazków, a jednak jej używasz).
Jesteś pewien? :) http://shootout.alioth.debian.org/u32/lua.php (pomijam już rozmiar biblioteki i łatwość integracji Lua&C++ z Java&C++)
« Ostatnia zmiana: Wrzesień 03, 2010, 00:07:08 wysłana przez Dab »

Offline yarpen

  • Użytkownik

# Wrzesień 03, 2010, 00:03:57
Cytuj
Użycie STL, Boosta, wzorców projektowych, enkapsulacji, stutuacji doprowadza do tego że 95% kodu to tzw. "glue code" który nic tak naprawdę nie robi.

Coś w tym jest. Na pewno trzeba uważać, aby nie przesadzić z poziomem abstrakcji.
Z drugiej strony i tak najwięcej roboty ma sam silnik graficzny + fizyka, a wyższe warstwy już nie muszą być jakieś bardzo szybkie, bo liczba obiektów na których pracują jest znacznie mniejsza (LUA jest znacznie powolniejsza od wszelkich Javopodobnych wynalazków, a jednak jej używasz).
Skad takie teorie? Obiektow fizycznych/renderowanych jest w wiekszosci przypadkow duzo mniej niz tych, ktorymi musi sie zajac AI/logika.

Offline bies

  • Użytkownik

# Wrzesień 03, 2010, 02:09:10
Java to ekstremalnie prosty język. To stanowi wprost o jego sile.
Omów różnicę w dostępie do pamięci z volatile przy przejściu z 1.4 na 1.5. Ekstremalnie prosty, tia...

Offline JCoder

  • Użytkownik

# Wrzesień 03, 2010, 10:20:17
@bies: przykład z volatile jest o tyle nietrafiony, że:
1. programowanie wątków zawsze było, jest i będzie trudne, niezależnie od języka
2. C++ ma pod tym względem o wiele większe grzechy; łącznie z przenikaniem stanu do osobnego wątku poprzez zmienne, które są częścią współdzielonej struktury, a same nie są współdzielone.
3. 1.4 to prehistoria; to tak jakbym powiedział, że GCC 2.95 nie umiało kompilować template'ów.

@yarpen:
Cytuj
Skad takie teorie? Obiektow fizycznych/renderowanych jest w wiekszosci przypadkow duzo mniej niz tych, ktorymi musi sie zajac AI/logika.

Oh, really? A jeden renderowany obiekt fizyczny to zapewne jest jeden trójkąt, tak? :D
Slajdy Carmacka o UE potwierdzają to co napisałem. Nie mówiąc o tym, że AI wielu niewidocznych obiektów nie musisz analizować co klatkę.

@Dab:
Jak się chce wykazać, że Java jest powolna, to się robi porównania do Java z opcją -Xint. Tyle, że na taką socjotechnikę nas nie nabierzesz.

http://shootout.alioth.debian.org/u32/benchmark.php?test=all&lang=lua&lang2=javasteady
Ja tu widzę różnice 15x-50x na niekorzyść LUA.

Offline Liosan

  • Redaktor

# Wrzesień 03, 2010, 10:30:22
3. 1.4 to prehistoria; to tak jakbym powiedział, że GCC 2.95 nie umiało kompilować template'ów.
I oba argumenty byłyby równie dobre - ostatnio gadałem z kolesiem, który pisał soft na jakieś urządzenia podłączane do telewizorów, i tam mieli tylko javę 1.3 ;)

Oh, really? A jeden renderowany obiekt fizyczny to zapewne jest jeden trójkąt, tak? :D
Slajdy Carmacka o UE potwierdzają to co napisałem. Nie mówiąc o tym, że AI wielu niewidocznych obiektów nie musisz analizować co klatkę.
Nie uważasz, że nierenderowanie niewidocznych obiektów jest jednak trochę prostsze niż nieanalizowanie AI niewidocznych obiektów? ;)
Zresztą, pomijasz argument Daba - obiekty fizyczne i logiczne to przede wszystkim interakcje par obiektów, w renderingu pod tym kątem przetwarza się tylko grupy obiektów.

Liosan
« Ostatnia zmiana: Wrzesień 03, 2010, 10:42:53 wysłana przez Liosan »

Offline bies

  • Użytkownik

# Wrzesień 03, 2010, 10:38:53
@bies: przykład z volatile jest o tyle nietrafiony, że:
1. programowanie wątków zawsze było, jest i będzie trudne, niezależnie od języka
Trafiony. Opis działania volatile jest trudny. I to nie chodzi o wątki bo synchronized jest o rząd wielkości łatwiejszy do zrozumienia niż DCL-pattern na przełomie 1.4/1.5. Ale żeby to wiedzieć trzeba napisać w Javie kiedyś coś więcej niż FooSmooBullshit extends HttpServlet.

Co do C++: ,,a u was biją murzynów'' -- nie wspominałem o C++.

3. 1.4 to prehistoria; to tak jakbym powiedział, że GCC 2.95 nie umiało kompilować template'ów.
Primo umiało (jakoś). Secundo circa 50%*) firm z polskiego (a pewnie na świecie też, ale klientów mam zazwyczaj w Polsce) Top500 używa 1.4 na serwerach. Są tacy co używają nawet 1.1 (bez JITC) z powodu specyficznego sprzętu i JVM. Ale znów to zazwyczaj nie jest FooShmooBullshit.

*) Tj. o tych firmach wiem. Ile naprawdę nie mam pojęcia, te procenty można traktować jako dolną granicę.
« Ostatnia zmiana: Wrzesień 03, 2010, 10:41:30 wysłana przez bies »

Offline JCoder

  • Użytkownik

# Wrzesień 03, 2010, 11:04:11
Cytuj
Nie uważasz, że nierenderowanie niewidocznych obiektów jest jednak trochę prostsze niż nieanalizowanie AI niewidocznych obiektów? Wink
Zresztą, pomijasz argument Daba - obiekty fizyczne i logiczne to przede wszystkim interakcje par obiektów, w renderingu pod tym kątem przetwarza się tylko grupy obiektów

Tak, tylko że mimo wszystko w renderingu nadal masz miliony obiektów, a w AI kilka rzędów mniej. Co do interakcji, to jeśli musisz przetwarzać każdą parę obiektów, aby uwzględniać ich interakcje to masz coś zrąbane z algorytmiką. Najczęściej obiekty reagują z obiektami sąsiadującymi. Czyli koszt jest nadal proporcjonalny do łącznej liczby obiektów.

Poza tym LUA jest jakieś 15-50x powolniejsza niż Java/C/C++, a mimo to jest bardzo popularna do realizacji najwyższych warstw gier.  Dlatego słowa o narzutach wywołań wirtualnych czy innych abstrakcyjnych konstrukcji w C++ (gdzie one są stosunkowo tanie) w ustach kogoś, kto wykorzystuje LUA w swoich produkcjach, brzmią co najmniej śmiesznie. A taki był oryginalny kontekst mojej wypowiedzi (a nie licytowanie się o liczbę obiektów czy szybkość LUA ws. reszta świata). Są miejsca w grze, gdzie wyższy poziom abstrakcji jest bardzo wskazany, nawet kosztem niewielkiego narzutu na wywołanie wirtualne czy inną wartwę pośrednią.

@bies: Stare wersje JDK są używane, tylko nie bardzo widzę sens porównywać je z technologiami współczesnymi. Jeśli robimy takie wybiegi, to może porozmawiamy o programowaniu w C++ 15 lat temu? Na niektóre platformy jak masz GCC 2.95 to jesteś farciarz. Nadal wiele projektów musi się kompilować na zabytkach, na które jedyne co jest to kompilator C z klasami, który wysypuje się przy obsłudze wyjątków a o szablonach w ogóle nie słyszał. Ilość problemów, na jakie trzeba być przygotowanym, jest wieloktrotnie wyższa niż wszystkie zmiany specyfikacji Java 1.1 do 6. Kod pisany pod 1.1 nadal w większości przypadków uruchamia się pod 6.0.

Cytuj
Primo umiało (jakoś)

"Jakoś" jest tu kluczowym słowem. Kompilowało najprostsze konstrukcje, czasem produkowało błędny kod.

Cytuj
Co do C++: ,,a u was biją murzynów'' -- nie wspominałem o C++.

Problem z DCL, który opisujesz dla Javy pre 1.5, jest jeszcze większy w C++ i wielu innych językach. Generalnie DCL jest "fundamentally broken" i nie powinno się tego w ogóle używać.

http://www.aristeia.com/Papers/DDJ_Jul_Aug_2004_revised.pdf

Cytuj
Nothing you do can alter the fundamental problem: you need to be able
to specify a constraint on instruction ordering, and your language [C++] gives you no
way to do it.

W Java 1.5 to jest rozwiązane, ale i tak nie ma sensu stosować DCL, bo Java natywnie obsługuje singletony i są one thread-safe.
DCL musieli wymyśleć programiści C++. Masz pretensje, że niedziałający wzorzec w C++, nie działa również w Javie < 1.5?

Cytuj
Finally, DCLP and its problems in C++ and C exemplify the inherent difficulty
in writing thread-safe code in a language with no notion of threading (or
any other form of concurrency). Multithreading considerations are pervasive,
because they affect the very core of code generation. As Peter Buhr pointed
out [3], the desire to keep multithreading out of the language and tucked away
in libraries is a chimera. Do that, and either (1) the libraries will end up putting
constraints on the way compilers generate code (as Pthreads already does) or
(2) compilers and other code-generation tools will be prohibited from performing
useful optimizations even on single-threaded code. You can pick only two of
the troika formed by multithreading, a thread-unaware language, and optimized
code generation. Java and the .NET CLI, for example, address the tension by
introducing thread-awareness into the language and language infrastructure,
respectively [8, 12].
« Ostatnia zmiana: Wrzesień 03, 2010, 12:00:20 wysłana przez JCoder »

Offline bies

  • Użytkownik

# Wrzesień 03, 2010, 12:28:43
Odstaw chochoły, nie rozmawiamy o C++. Nie rozmawiamy o DCL (to przykład na którym dobrze widać problem z membarriers). Rozmawiamy o tym, że Java jest trudna. Innym przykładem byłby np. tuning GC -- też rzecz o której typowy javowy średniak nie ma bladego pojęcia. A właściwie to w ogóle nie rozmawiamy bo wciąłeś się w odpowiedź nie do siebie...

A jeśli już koniecznie chcesz dowiedzieć się czegoś o C++: w C++ masz rozszerzenia kompilatora (w tym __asm__ __volatile__) które pozwalają (od wielu, wielu lat) napisać DLCP poprawnie na dowolną platformę. Standard języka nie precyzuję wątków, środowiska (system, kompilator, runtime) o bardzo dawna.

A jak już piszesz o 2.95 to dawaj konkrety -- na jakie platformy używa się jeszcze 2.95?

Offline Dab

  • Redaktor
    • blog

# Wrzesień 03, 2010, 12:33:26
Cytuj
Tak, tylko że mimo wszystko w renderingu nadal masz miliony obiektów, a w AI kilka rzędów mniej.

Jakie miliony, kolego, chyba żeś się z komputera kwantowego urwał. Jeżeli liczysz trójkąt jako obiekt to fajnie -- może w logice/AI liczmy każdy bajt jako obiekt? :D

Cytuj
Jak się chce wykazać, że Java jest powolna, to się robi porównania do Java z opcją -Xint. Tyle, że na taką socjotechnikę nas nie nabierzesz.

Nie znam się na Javie i w szczególności nie mam pojęcia co to za opcja. W każdym razie moje doświadczenia jakoś nie pokazują że Lua jest szczególnie wolna a Java szczególnie szybka. Weź pod uwagę, że 99% skryptów to:

sprawdź globalną zmienną
jeżeli 0 to pokaż komunikat
jeżeli 1 to
{
ustaw animację Foo
przesuń światło Bar
}


I teraz weź pod uwagę że sam narzut na wywołanie machiny JVM będzie dużo większy niż wywołanie kilku funkcji Lua. Jako że trzymam sobie kod źródłowy Lua to wiem że wywołanie skryptu Lua nie przekracza zagnieżdżenia 10 funkcji C -- powiesz to samo o Javie? :) Szybkość wykonywania samego skryptu nie jest istotna (no chyba że ktoś liczy w nich fizykę cząsteczkową -- powodzenia).