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

Offline JCoder

  • Użytkownik

# Wrzesień 03, 2010, 13:09:04
Cytuj
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?

Wywołanie Java->C++ zwykle jest 4-10 razy wolniejsze niż wywołanie Java->Java lub C++ -> C++. Więc remis.

Cytuj
Rozmawiamy o tym, że Java jest trudna.

Tiaa. Tylko jako przykład podałeś coś, co:
1. W C++ jest jeszcze trudniejsze.
2. W Javie nie ma racji bytu, bo konstrukcja singletonów jest przewidywalna. Nie mówiąc o tym, że problem od 1.5 w górę nie występuje.

GC trudne w strojeniu? Żartujesz. GC stroi się tak:
1. ile mamy RAMu? 512 MB. Ok to dajemy: -Xmx512M, koniec roboty.
2. hmm, zacina się -> spróbuj innego GC
3. zacina się dalej -> spróbuj innego GC
4. wypróbowałeś wszystkie GC i się nadal zacina? To nie GC. Skwasiłeś implementację. Popraw i wróć do 2.

Strojenie GC jest trudne tylko wtedy, gdy chcesz za wszelkj cenę wycisnąć z JVM aby używał minimum RAMu i równocześnie chodził szybko. Ale nadal nie jest to trudniejsze niż napisanie po prostu efektywnego kodu.


Offline Mr. Spam

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

Offline bies

  • Użytkownik

# Wrzesień 03, 2010, 13:52:33
Cytuj
Rozmawiamy o tym, że Java jest trudna.
Tiaa. Tylko jako przykład podałeś coś, co:
1. W C++ jest jeszcze trudniejsze.
A ja nie twierdziłem, że w Javie jest trudniejsze od C++. W ogóle nie pisałem o C++. Po co mi C++ w wyjaśnianiu Siso, że Java jest trudna? Masz jakiś problem z C++, że wszędzie widzisz krzyżyki. Świat nie kończy się na C++. O co Ci chodzi z tym C++?

2. W Javie nie ma racji bytu, bo konstrukcja singletonów jest przewidywalna. Nie mówiąc o tym, że problem od 1.5 w górę nie występuje.
Kurde, potrafisz w ogóle czytać? Trudny jest opis zmiany działania volatile w 1.4 i 1.5. Sam opis działania volatile jest w ogóle trudny (bo nagle okazuje się, że trzeba wiedzieć co to jest cache procesora na którym działa JVM). DLCP to tylko przykład -- volatile używa się w wielu innych przypadkach.

GC trudne w strojeniu? Żartujesz. GC stroi się tak:
1. ile mamy RAMu? 512 MB. Ok to dajemy: -Xmx512M, koniec roboty.
2. hmm, zacina się -> spróbuj innego GC
3. zacina się dalej -> spróbuj innego GC
4. wypróbowałeś wszystkie GC i się nadal zacina? To nie GC. Skwasiłeś implementację. Popraw i wróć do 2.

Strojenie GC jest trudne tylko wtedy, gdy chcesz za wszelkj cenę wycisnąć z JVM aby używał minimum RAMu i równocześnie chodził szybko. Ale nadal nie jest to trudniejsze niż napisanie po prostu efektywnego kodu.
Skąd Ty się urwałeś? Masz serwer aplikacyjny pisany przez ostatnie 10 lat przez niezliczone rzesz programistów. Masz instrukcje wdrożenia i noty do instrukcji tak duże, że cykl szkoleniowy dla wdrażających zajmuje ponad miesiąc nie licząc żadnego doświadczenia. I masz np. notę o wdrożeniu na JVM na Solarisie na procesorach Niagara i strojeniu GC pod 64-rdzeniowy procek. Co chcesz napisać od nowa? Masz w ogóle pojęcie jak wygląda produkcyjne używanie Javy w dużych systemach (obsługujących > 2K użytkowników)?

Googlnij sobie za ,,JVM GC tuning'' -- powinieneś dostać dokumenty przynajmniej dla Oracle i IBM.

Offline siso

  • Użytkownik

# Wrzesień 03, 2010, 14:51:14
Bies, no i po co tak się od razu denerwować? :)

Volatile nie było i nie jest nagminnie używanym feature'm języka. Rozmawiamy o twórcach aplikacji w końcu czy o twórcach frameworków, specjalizowanych bibliotek albo wręcz "bogach" kodujacych trzewia JVM? Ci ostatni to nawet nie w Javie piszą, zresztą. Wydawało mi się, że rozmawiamy o "programistach aplikacji", których jedynym celem powinno być skupienie się na spełnieniu wymagań projektowych przy zastosowaniu wszelkich możliwych środków jakie mogą to zadanie ułatwić. Pozwoliłem sobie wcześniej powołać się na taką właśnie "większość".

Jeśli volatile przed 1.5 zachowywało się odrobinę inaczej niż teraz i dodamy do tego, że było może słabo udokumentowane, a do tego jest to ciężki kawałek chleba w ogólności - to trudno. Tak jest i koniec. Ale ten jeden przykład nie pokazuje nijak, że cały język jest trudny. Bo nie jest. 99% zastosowań (że tak sobie z własnego doświadczenia oszacuję) wymaga od programisty znajomości bardzo prostych rzeczy. Piszę w Javie zawodowo bez mała już 6 lat i do tej pory miałem może jeden raz (no, niech dwa, już trudno) konieczność użycia volatile. Przyczyna? Grupy projektowe siedzą i myślą i zadają zęby tylko po to, by reszta mogła pisać komponentowe aplikacje uruchamiane w gotowych, wyspecjalizowanych serwerach aplikacji, które mają wyznaczony standardem obowiązek zapewniania bezpieczeństwa wątków, jeśli takie są wymagania. I nie dotyczy to tylko volatile. Z pozostałymi rzeczami - a zaczęło się od refleksji - jest podobnie.

W Javie schody zaczynają się zazwyczaj nie na poziomie języka, a na poziomie architektur. To jest największa bolączka javowego świata. Ale i na to są sposoby.

Jeszcze kwestia legacy code / legacy systems...
Jak masz legacy system chodzący na jakimś archaicznym/egzotycznym sprzęcie/sofcie i musisz go rozwijać o nowe feature'y, to lepiej pakuj walizki i wiej gdzie pieprz rośnie. Jedyne uzasadnienie biznesowe dla utrzymania takich systemów to ich (najczęściej wątpliwej już jakości) funkcjonalność, której "obecnie nie ma czym zastąpić". Bzdura - zawsze są lepsze alternatywy. Lub też "nie da się, bo wymiana jest za droga". Następny bullshit - utrzymanie starego gówna i tak w końcu okazuje się droższe, zaś decyzja o wymianie zapada, gdy najwyższy management zorientuje się łaskawie, jak bardzo jest w d..pie i że trzeba było tą decyzję podjąć trzy lata temu. Jeśli właściciel systemu nie ma poczucia beznadziejności sytuacji i ciągle wymaga łatania i dokładania nowych feature'ów, optymalizacji i Bóg wie czego jeszcze, wtedy patrz: uwaga o walizkach.

W moim skromnym doświadczeniu zawodowym jeszcze nie spotkałem nikogo, komu na zdrowie wyszło by w perspektywie tuningowanie GC pod jakieś dziwactwa czy łatanie jakichś choćby dziur w bezpieczeństwie tylko dlatego, że management nie chce wyłożyć kasy na przebudowę. Nie po to mamy ciągle rozwijające się standardy, żeby tkwić w średniowieczu. Albo używać produktów niszowych. Zobacz, co robi Google w kwestii serwerów - nawet serwerów nie używa, tylko ogólno dostępne, zwykłe klocki. I współczesny soft.
A jeśli nawet - są jeszcze ludzie, którzy te stare systemy pisali. Niech oni się martwią, jak to dzisiaj łatać. A jeśli sam chcesz się o to martwić - po to masz dokumentację i soft właściwy dla danego przypadku. Jeśli nie masz -> walizki.

Mówię tu oczywiście o Javie EE. Jeśli ktoś chce w SE pisać jakiś zaawansowany system, to pozostaje mu tylko współczuć. Zdecydowanie nie do tego to służy. A próba maintenace'u czegoś o wieloletniej historii to już zwyczajne proszenie się o seppuku. Przez umpa - pumpa, żeby nie było za łatwo.

Offline JCoder

  • Użytkownik

# Wrzesień 03, 2010, 16:13:36
@bies: w każdym języku są jakieś haczyki, czy elementy trudniejsze do pojęcia. Nie chcesz porównań do C++, proszę bardzo. W Pythonie, Rubym i innych też znajdziesz kilka rzeczy, które będą względnie trudne do zakumania - szczególnie jeśli chodzi o kwestie programowania współbieżnego. Po prostu jest to trudne z definicji i tyle. Siso chodziło o to, że Java jest względnie jednym z najprostszych języków do kodowania aplikacji i ja to w pełni potwierdzam. Ale nie oznacza, to że byle debil może w tym programować, bo kończy się to źle. Tak samo jak w PHP.

Odnośnie volatile: w ciągu 7 lat użyłem może ze dwa czy trzy razy. Refleksji nieco częściej, ale tylko w kodzie jakiegoś frameworku. Zwykły koder w ogóle nie powinien się dotykać do wątków, bo predyspozycje do zakumania wątków / pisania silników ma może 2% programistów i to niezależnie od języka.

Cytuj
Masz w ogóle pojęcie jak wygląda produkcyjne używanie Javy w dużych systemach (obsługujących > 2K użytkowników)?

2K ???  Chciałeś chyba napisać 2M? :D

A wygląda to najczęściej tak, że serwery aplikacyjne (Java) się nudzą, a baza (C lub C++) się poci. Strojenie GC to pikuś przy strojeniu bazy.

« Ostatnia zmiana: Wrzesień 03, 2010, 16:15:37 wysłana przez JCoder »

Offline siso

  • Użytkownik

# Wrzesień 03, 2010, 16:29:56
Cytuj
A wygląda to najczęściej tak, że serwery aplikacyjne (Java) się nudzą
A jak przestają się nudzić, to się im dokłada "braci" ;) Nawet 50+ fizycznych maszyn serwerowych na jedną skalującą się aplikację to nie jest dzisiaj żaden problem.

Offline Liosan

  • Redaktor

# Wrzesień 03, 2010, 16:47:27
A wygląda to najczęściej tak, że serwery aplikacyjne (Java) się nudzą, a baza (C lub C++) się poci. Strojenie GC to pikuś przy strojeniu bazy.
Bo taniej dołożyć nowy serwer niż zmusić przekonać poprosić programistów aplikacji by napisali ją wydajnie?

Liosan

Offline JCoder

  • Użytkownik

# Wrzesień 03, 2010, 17:06:11
Czasem tak, a czasem nie. Zawsze się kalkuluje koszty. Jeśli można poprawić wydajność aplikacji korygując jakieś oczywiste spowalniacze, to się robi to w pierwszej kolejności. Serwery wbrew pozorom też niemało kosztują. Jeśli jednak optymalizacja miałaby polegać na posadzeniu gościa na miesiąc lub dwa, to czasem taniej dostawić parę serwerów.

Offline siso

  • Użytkownik

# Wrzesień 03, 2010, 17:08:00
A wygląda to najczęściej tak, że serwery aplikacyjne (Java) się nudzą, a baza (C lub C++) się poci. Strojenie GC to pikuś przy strojeniu bazy.
Bo taniej dołożyć nowy serwer niż zmusić przekonać poprosić programistów aplikacji by napisali ją wydajnie?

Liosan
Zdecydowanie taniej.
Taniej niż zmusić przekonać poprosić programistów JVM/serwera aplikacji/frameworków/bibliotek by napisali swoje rzeczy wydajniej.
A także taniej, kiedy czas programistów aplikacji jest wykorzystywany do zaspokajania celów biznesowych, zamiast jakichkolwiek innych, które da się załatwić innymi metodami.

Offline Dab

  • Redaktor
    • blog

# Wrzesień 03, 2010, 17:09:32
No fajnie. A teraz wracamy do gamedevu. Rozumiem że minimalne wymagania gry na poziomie "farma 40 serwerów" was przekonują? :D

Offline siso

  • Użytkownik

# Wrzesień 03, 2010, 18:05:37
Niech pomyślę...
Tak, na 40 już się powinno dać coś sensownego zapuścić ;)

Offline JCoder

  • Użytkownik

# Wrzesień 03, 2010, 18:24:37
Witcher Versus przy ponad milionie użytkowników potrzebował 4 serwerów... :D
Z czego serwery aplikacyjne rzadko przekraczały 10% użycia CPU. A 4 tylko dlatego, żeby zapewnić odpowiedni poziom niezawodności w przypadku ewentualnego padu sprzętu. Jak padnie jeden serwer, aplikacja chodzi dalej.
« Ostatnia zmiana: Wrzesień 03, 2010, 18:26:36 wysłana przez JCoder »

Offline bies

  • Użytkownik

# Wrzesień 03, 2010, 19:07:20
Primo nie chodziło mi o 2M tylko 2K ale jednoczesnej pracy -- wystarczy. Secundo nie piszę o legacy systems tylko (min.) o EPR SAP. Aktualnie wspierana wersja (7.0.1) wymaga JVM 1.4, nowa wersja (7.1) wymaga JVM 1.5 ale nikt jeszcze na poważnie jej nie używa produkcyjnie. Nie ma ,,lepszych alternatyw'' dla SAP. Z tego samego podwórka jest optymalizacja GC pod Niagarę. Optymalizacja Oracle'a czy systemu to inna bajka -- robi się wszystko. Tertio 50 fizycznych maszyn to jest problem -- mówi się, że to małe koszta ale policzenie sobie 50 blade'ów od IBM (czy HP, nie jestem wybredny) wraz z chassis, systemami i kosztem zasilania sumuje się ładnej kwoty.

Piszecie, że Java jest łatwa przy prostych projektach. Każdy język jest łatwy przy prostych projektach. Sam potrafię ustalić taki standard, że C++ też będzie prostym językiem (pisaliście kiedyś aplikację okienkową w Qt -- banał). Niestety to nic nie znaczy. Szybko się okazuje, że trudne projekty są trudne w dowolnym języku.

Offline JCoder

  • Użytkownik

# Wrzesień 03, 2010, 19:42:27
Cytuj
Szybko się okazuje, że trudne projekty są trudne w dowolnym języku

Trudne projekty są trudne, ale w pewnych językach nawet trudniejsze. :P
Jak masz trudny projekt, to cokolwiek co zmniejsza Ci ilość problemów choćby trochę, to dobra rzecz.
Java jednak dosyć mocno ułatwia pisanie właśnie dużych projektów; gdzie jest dużo osób o różnym poziomie umiejętności.