ulubiony język

@Max1414:

Ad 1. Ranides napisal Ci dlaczego czas kompilacji jest wydluzony - ze wzgledu na optymalizacje. Program kompiluje sie kilka razy (docelowo raz), uzywa milion - widzisz tutaj roznice?

Ad 2. Co do czytelnosci tego kodu sie nie bede wypowiadal, bo to co podales jest mocno tendencyjne. Popatrz przykladowo na kod napisany samodzielnie przez poczatkujacego (bez obrazy dla autora) - aktualnie pierwszy z brzegu w Newbie. To jest wlasnie to co mamy na mysli, kiedy mowimy o przejrzystosci. Rzut okiem na kod i juz wiadomo co sie dokladnie dzieje.

Co do nie jechania na C++ Buildera. Tak sie sklada, ze uzytkownicy tego srodowiska to zdecydowana mniejszosc. Co wiecej sa to albo bardzo poczatkujacy, ktorzy nie wiedza co sie dzieje albo zaawansowani programisci, ktorzy doskonale wiedza co robia i dlaczego akurat takie srodowisko wybrali. Bo samo srodowisko nie jest zle, tak jak Delphi tez nie jest zle. Ale patrzac na watki w dziale Delphi mam wrazenie, ze jedyne co sie tam robi to klika w TKlasy i nagle 'niedziala' (blad ort. celowy). Krytykowanie C++ Buildera mija sie z celem, bo jest wiele innych srodowisk, gdzie sie mozna w C++ wyzyc. Nie wiem czy w Delphi sa inne (a pewnie tak), ale zdecydowana wiekszosc zdaje sie uzywa Borlandowego.

Jest do object pascala IDE z zestawem narzędzi RAD: Lazarus, na licencji GPL. Ale daje binarki sporo większe niż Delphi, i w przeciwieństwie do Delphi jest i na Linuxa i inne unixopodobne systemy.

skullman napisał(a)

Co do naukowców i Fortrana to zgoda, ale nie tylko i nie wszędzie. Poza fizyką i matematyką są jeszcze inne dyscypliny. W naukach biologicznych i im pokrewnych dominuje C++ i python.

Jest jeszcze obecny w inżynierii szczególnie w stanach i na zachodzie europy. Rzecz w tym, że jest dużo bibliotek o FORTRANa, których przepisanie na np. C++ będzie niebezpieczne. Kwestia braku testów i możliwość popełnienia dużej liczby ukrytych błędów. Potem by powychodziły dziwne kształty skrzydeł w samolotach :)
Biologia z komputerem to wynalazek ostatnich 20-25 lat zatem biolodzy mieli możliwość wybrania sobie języka. Inżynierowie używają FORTRANa "od zawsze" czyli od lat 50tych. Co do COBOLa to miałem z nim bardzo krótką przygodę i wolę już chyba w prologu i datalogu pisać niż w COBOLu. Jednak należy pamiętać iż COBOL jeszcze długo będzie żył np. w amerykańskich bankach, bo koszty wymiany systemu są za duże i obarczone ryzykiem utraty lub przekłamania danych.

[edit]

Pytanie kto pisał w LOGO i dlaczego LOGO to jego ulubiony język. Znalazłem przed chwilą dyskietkę z kompilatorem pod DOSa 3.11i szukam starego PCeta z tym systemem... gdzieś ta skrzynka leży [diabel]

A propos powodow pozostawania przy FORTRANie. Kiedys moj wykladowca przy omawianiu STL'a wspomnial, ze pracuje z grupa badawcza nad przepisaniem FORTRANowych bibliotek obliczeniowych na c++. Nie pamietam ile to czasu zajmowalo, ale pamietam jak powiedzial, ze wreszcie zaczynaja osiagac zblizona szybkosc do FORTRANa. To tez o czyms swiadczy.

@koziolek; Ja pisalem, ale zdecydowanie nie jest to moj ulubiony jezyk ;)

Koziołek napisał(a)

Pytanie kto pisał w LOGO i dlaczego LOGO to jego ulubiony język. Znalazłem przed chwilą dyskietkę z kompilatorem pod DOSa 3.11i szukam starego PCeta z tym systemem... gdzieś ta skrzynka leży [diabel]

Ja w LOGO napisałem swoją pierwszą gierkę (wyścigi samochodowe) pod Atarynkę (stare dzieje ;) ).

Max: a Ty dalej swoje? Daj jakiś większy kawałek kodu w obu językach, jakiś algorytm nie korzystający z zew. bibliotek, tak jak napisał deus - wtedy porównamy czytelność, bo te 3 linijki które zaprezentowałeś.. ...no sorry...

skullman napisał(a)

Jest do object pascala IDE z zestawem narzędzi RAD: Lazarus, na licencji GPL. Ale daje binarki sporo większe niż Delphi, i w przeciwieństwie do Delphi jest i na Linuxa i inne unixopodobne systemy.

co to jest "Linuxa"? a "unixopodobne systemy"? juni-co? nie słyszałem.

Ranides napisał(a)

/ IRC? mogę wpaść i posłuchać - ja się na IRCach czuję zagubiony i zawsze piszę coś nie tak ;) /

Zagubiony? :) Zapraszamy, zawsze jakieś ciekawe tematy drążymy [diabel] [szczególnie późniejszym wieczorem] [browar]

Nie czytam tego tematu od początku ale czy niejakiemu Maxowi nie wpadło może do głowy, że pewnych rzeczy w delphi zrealizować (przynajmniej w cywilizowany sposób) się po prostu nie da ?
Przykładem są unie, w c++ banalne, w delphi nie ma w ogóle takiej konstrukcji. W sumie jedyny sposób aby zrealizować coś na kształt unii w delphi to stworzenie klasy która alokowała by potrzebną ilość pamięci równa największemu typowi danych a następnie udostępniała szereg właściwości w których dokonywane było by rzutowanie przydzielonej pamięci na konkretne typy danych. Żenada.... Innym przykładem może być chociażby przeciążenie operatorów. Zdecydowanie łatwiej jest napisać np vector1+vector2*3 niż VecAdd(vector1,VecMul(vector2,3)). W c++ wyszło zdecydowanie krócej i czytelniej, oczywiście przeciążenie operatorów ma dużo szersze zastosowanie. Można stworzyć automatyczne wskaźniki które zwolnią nas z zarządzania pamięcią, będą również zliczać referencje do obiektu i usuną go dopiero wtedy gdy naprawdę nie będzie on już używany co zapobiegnie błędom Access Violate. W tym przykładzie dochodzimy również do szablonów. Jeżeli klasę automatycznego wskaźnika stworzymy jako klasę szablonową będzie ona bardziej spójna np nie będą konieczne żadne rzutowania. Na tym nie kończą się oczywiście możliwości szablonów. Rozważmy dla przy kładu klasę managera zasobów, klasa ta powinna ładować oraz zwalniać pamięciożerne obiekty, a także zapobiegać ich duplikacji(tj. wielokrotnemu załadowaniu gdy inna kopia jest już obecna w pamięci) . Wszystko jest pięknie kiedy wszystkie klasy zasobów implementują wspólny interfejs. W takim przypadku (zakładając, że już mamy tę klasę) aby uzyskać dostęp do zasobu foo.dds należało by napisać w delphi PTexture3DResource(TxMgr.GetResource('foo.dds')) – żadnen problem ;) Cała zabawa zaczyna się dopiero wtedy gdy obiekty którymi będziemy zarządzać nie implementują naszego interfejsu bo np pochodzą z innej biblioteki. W delphi jesteśmy niemal bezradni (pozostaje RTTI i masa if'ów) w c++ możemy po prostu zaimplementować ten interfejs za pomocą wielodziedziczenia lub skonkretyzować szablon dla obiektów które należy traktować inaczej. Ba! Jeżeli wszystkie obiekty z tej biblioteki obsługuje się tak samo (np posiadają one metodę Load i Unload) Wystarczy tylko 1 klasa dla wszystkich tych obiektów nawet jeżeli nie maja one wspólnego interfejsu (w sensie klasy bazowej), a konkretyzację przeprowadzamy dla obiektów wywodzących się z naszego IResource. W ten sposób otrzymujemy zintegrowany system zarządzania zasobami przy minimalnym nakładzie kodu. W delphi prawdopodobnie musielibyśmy duplikować kod dla każdej klasy z tej zewnętrznej biblioteki. Już nie wspominam o funktorach (klasach które zachowują się jak funkcje). Po prostu delphi miało być czymś pomiędzy visual basicem a c++ i faktycznie właśnie tym jest i nie ulega wątpliwości, że możliwości ma dużo mniejsze niż c++.

Że jest trudniej, nie oznacza, że się nie da. Brak niektórych konstrukcji językowych (wymienione unie, szablony i przeciążanie) da się zawsze obejść, choć zgodzę się, że będzie to czasem karkołomne. Zresztą ten argument już był. Cała dyskusja o Delphi vs C++ jest głupia - wątek był o ulubionym języku, a nie o tym, który język OBIEKTYWNIE jest lepszy. Czyli opinie miały być subiektywne. ile razy jeszcze wymienicie co ma C++, a czego nie ma Delphi i na odwrót?

Moja SUBIEKTYWNA opinia na temat C++ i Delphi jest taka, że oba są do d**y bo nie dają natywnego sposobu do pracy na danych relacyjnych, tak jak daje PL/SQL. :-P No proszę, kto napisze mi w C++ lub Delphi nie używając SQLa program, który robi:

SELECT * FROM tabela1 NATURAL JOIN tabela2 WHERE x = 6 GROUP BY y HAVING sum(z) > 5 ORDER BY sum(z);

Dla uproszczenia obie tabele zawierają razem tylko 1 TB danych. Ciekawe, czy ktoś się wyrobi w mniej niż 100 linijkach.

@Koziołek: jest jeszcze jeden aspekt: lubimy zwykle języki, które znamy.
Czasem obiektywnie nieco słabszy do danego zadania język, dla konkretnej osoby może być lepszym wyborem. Jeśli dać programiście VB do napisania aplikację okienkową, nie będzie uczył się Delphi, mimo że wiele osób uznaje je za lepsze narzędzie. Napisze to w VB i najprawdopodobniej zajmie mniej niż nauka i pisanie w Delphi.

C++ za to, ze jest trendy, co znaczy, ze jesli chce zrobic aplikacje wykorzystujaca np PhysXa to sciagam SDK i robie, nie musze sie obawiac, ze jakas biblioteka nie ma bindow do mojego jezyka.

Zombiak napisał(a)

Przykładem są unie, w c++ banalne, w delphi nie ma w ogóle takiej konstrukcji.

Radzę dokładniej poznać Delphi. Przykład uni (TRect):

type 
TPoint = record
  X: Longint;
  Y: Longint;
end;

TRect = record
  case Integer of
    0: (Left, Top, Right, Bottom: Integer);
    1: (TopLeft, BottomRight: TPoint);
  end;

A ja Ci radze przeczytac tresc tematu!!

Moimi ulubionymi jezykami sa asm i c. Lubie je i juz nie wiem dlaczego ;). Nauke zaczalem w c++ i tez go uzywam do swoich projektow ale i tak wole wyzej wymenione. No i jeszcze perla do parc administracyjnych.
Do tworzenia stron chce sie nauczyc rubyiego bo jak patrze na php to mi sie zygac chce, ale jeszcze nie wiem co z tego wyjdzie :).

Pozdrawiam

C i asm.

Była tu mowa o tym, czego uzywają naukowcy. Właśnie natknąłem się na to:

"For example, IBM Watson's Ninja project showed that Java can indeed perform BLAS matrix computations up to 90% as fast as optimized Fortran"

Więcej tu:

http://dsd.lbl.gov/~hoschek/colt/

Jak widać w CERN też lubią Javę. Bynajmniej nie do apletów edukacyjnych. :P

A dla niedowiarków jeszcze jeden przykład:
http://searchwebservices.techtarget.com/originalContent/0,289142,sid26_gci1261398,00.html

@Krolik, tylko nie powiedzieli, że innych algorytmów używają mn. wielowątkowości na maszynach wieloprocesorowych co w FORTRANIE nie do końca jest możliwe. Trzeba wątki emulować ręcznie i w dodatku nie zawsze to wychodzi. Niby w F95 i F2003 już są POSIXowe watki, ale starasznie to jeszcze kuleje.
Jednak pomysł jest niezły i zapewne za niedługo będzie jeszcze fajniej.

Brainfuck jest świetny, to każdy przyzna ;)
A tak na serio to C++ do kolejnych prób przybliżających mnie do napisania upragnionego silnika graficznego, a Python do 'codziennych' programów (proste użytki, typu układanie playlisty do winapa) i skrypty do Blendera. Poza tym bawiłem się trochę asemblerem, co prawda nie wyszedłem poza poziom jednosegmentowych programów pisanych na przerwaniach ;)
Z innych znańszych - z Delphi nie miałem styczności, a co o myślę o Javie to już chyba kiedyś napisałem, w skrócie: zupełnie nie nadaje się do moich zastosowań. Gdy trzeba walczyć o każdy cykl procesora to burżujstwa w stylu maszyn wirtualnych czy kompilacji w locie są jakby nie na miejscu ;) Rozumiem jednak, że są zastosowania w których szybkość nie ma aż takiego znaczenia, więc nie będę dolewał oliwy do ognia w toczącej się dyskusji ;)

@Ghostek, pytanie kontrolne dlaczego zatem jave używano w komórkach, MDA/PDA i inszych urządzonkach o małych zasobach.
Do "codziennych" pseudo skryptowych zabawek pod windą java jest wyśmienita :)

Koziołek napisał(a)

@Ghostek, pytanie kontrolne dlaczego zatem jave używano w komórkach, MDA/PDA i inszych urządzonkach o małych zasobach.

Bo aplikacje ladnie sie przenosza miedzy architekturami. Spodziewales sie odpowiedzi, ze jest mniej zasobozerna niz jakis C?

@Wolverine, jako pierwszego fragmentu. Java jest szybka jednak stare (1.5 i w dół) pakiety są troszkę przeładowane i mało zoptymalizowane. Java 1.6 jest już w znacznym stopniu zoptymalizowana i prawie tak szybka jak C++ :)

Koziołek napisał(a)

i prawie tak szybka jak C++ :)

No niezupełnie. Obecnie jest czasem szybsza, czasem wolniejsza, zależy od konkretnego programu, ale różnice zwykle nie są duże. Po prostu inne optymalizacje robi C++, inne Java. JIT może przeprowadzać optymalizacje, których nigdy nie da się zrobić w C++. Poza tym JIT optymalizuje kod pod konkretny procesor, wykrzystując pełny zestaw instrukcji, podczas gdy w praktyce programy pisane w C++ są kompilowane na jakiś wspólny mianownik np. 486 lub 586.

Ale nawet skompilowanie w C++ pod konkretny procesor nie gwarantuje, że ten kod będzie się wykonywał szybciej niż na JVM bo np:

• JIT może inlineować funkcje wirtualne, C++ nie.
• JIT może usuwać niepotrzebne blokady (czasem do 80%) na podstawie Escape Analysis, C++ nie.
• JIT agresywniej używa rejestrów, ponieważ nie musi się martwić o aliasing wskaźników jak w C
• Alokacja i dealokacja pamięci w Javie jest średnio kilka razy tańsza niż w C++. Problem fragmentacji pamięci w Javie nie występuje.
• W Javie więcej i łatwiej się operuje na wskaźnikach ze względu na GC, w C++ łatwiej niechcący "coś dużego skopiować" zamiast przekazać; czasem wręcz trzeba się namotać jak się STLa używa, żeby wyeliminować kopiowanie.
• JIT może alokować typowo między 5% a 80% obiektów tworzonych przez new() na stosie dzięki Escape Analysis. Ta optymalizacja obecnie NIE JEST JESZCZE STOSOWANA (mimo obecności samej EA w Javie 6). Ponoć ma być w Javie 7. Ze wstępnych badań ta optymalizacja daje kolejne kilkanaście procent zysku na wydajności.
• JIT efektywniej korzysta z maszyn wieloprocesorowych, bo np. GC może działać równolegle. Co oznacza, że jednowątkowy program też zyskuje troszkę na obecności drugiego rdzenia. W C++ nie.

Dużą bolączką Javy jest tylko czas startowania aplikacji. Wiem, że nad tym pracuja. W Javie 6 względem 5 przyspieszyli czas startu ponad dwukrotnie. Czekam na więcej, bo to nadal za mało.

// komunizm dzielnie walczy z trudnościami, jakie w innych ustrojach nie wystepuję ;) - Q

Krolik napisał(a)

Dużą bolączką Javy jest tylko czas startowania aplikacji. Wiem, że nad tym pracuja. W Javie 6 względem 5 przyspieszyli czas startu ponad dwukrotnie. Czekam na więcej, bo to nadal za mało.

Niekoniecznie dużo czasu. Zaobserwowałem że na windzie wystarczy raz uruchomić JVM i potem każda następna aplikacja korzysta z tej samej JVM. Java zostaje jako proces w systemie i choć można ją ubić to rzadko kiedy użytkownicy to robią. Zatem wystarczy, teoretycznie, wrzucić coś banalnego do autostartu i wtedy system będzie się dłużej uruchamiał jednak aplikacje będą startowały szybciej. Oczywiście pozostaje problem zajętych zasobów, ale patrząc na współczesne kompy to chyba nie będzie aż tak bolesne.
@Krolik, świetne opracowanie.

Faktycznie, zapomniałem, że na Windows zrobili Class Data Sharing. Tylko czemu nie ma tego w Linux? Dobra, dosyć już gadania o Javie, bo się offtop zrobił.

Pogadajmy o Groovym. Ktoś coś w tym pisał?

No. Tradycyjna swieta wojana jak za czasow Commodore C64 i Atari. Panowie, tylko spokoj moze nas uratowac. Moim zdaniem kazdy jezyk jest dobry zastosowaniach do ktorych zostal zaprojektowany i nie warto sie ograniczac do jednego, a tym bardziej trzymac sie kurczowo jakis nielogiczych przeslanek. Jak sie programuje, mozna napisac wyszysko co potrzeba w jezyku, ktory do tego sluzy.

spc napisał(a)

No. Tradycyjna swieta wojana jak za czasow Commodore C64 i Atari.

Jaka wojna? Jakie nielogiczne przesłanki?
Oczywiście, że trzeba dobierać język do zastosowania, ale w 90% przypadków dla kogoś kto dobrze zna Javę najlepszym wyborem jest Java :P. I dlatego na razie jest to mój ulubiony język. Choć korci mnie trochę do Rubyego... :D

Koziołek napisał(a)

@Ghostek, pytanie kontrolne dlaczego zatem jave używano w komórkach, MDA/PDA i inszych urządzonkach o małych zasobach.

Ekhm... bo owe aplikacje nie są tak skomplikowane?

Do "codziennych" pseudo skryptowych zabawek pod windą java jest wyśmienita :)

To już kwestia gustu - ja pozostaję przy zdaniu, że Python rządzi ;)

Krolik napisał(a)

Ale nawet skompilowanie w C++ pod konkretny procesor nie gwarantuje, że ten kod będzie się wykonywał szybciej niż na JVM bo np:

• JIT może inlineować funkcje wirtualne, C++ nie.
• JIT może usuwać niepotrzebne blokady (czasem do 80%) na podstawie Escape Analysis, C++ nie.
• JIT agresywniej używa rejestrów, ponieważ nie musi się martwić o aliasing wskaźników jak w C

Tylko zauważ, że mimo wszystko Java startuje z gorszej pozycji niż języki kompilowane, bo przecież kompilacja w trakcie wykonywania swoją porcję zasobów zżera, i nie wmówisz mi że jest to do pominięcia ;) A poza tym, w C++ nie ma większego problemu z napisaniem krytycznych dla wydajności fragmentów kodu w asemblerze, więc nie trzeba zawsze zdawać się na łaskę i niełaskę kompilatora.

• Alokacja i dealokacja pamięci w Javie jest średnio kilka razy tańsza niż w C++. Problem fragmentacji pamięci w Javie nie występuje.

Też zależy od tego, jak kto programuje - wiadomo, że trzymanie wielkich kontenerów wskaźników z których każdy jest alokowany dynamicznie pofragmentuje pamięć jak cholera i zeżre przy tym mnóstwo zasobów na alokację i dealokację. Z drugiej strony, jeśli trzymać dane w jednorazowo alokowanych wielkich blokach i trzymać wskaźniki na fragmenty tych bloków, to narzut związany z alokacją odpada a z fragmentacją można poradzić sobie we własnym zakresie (przy ustandaryzowanych rozmiarach fragmentów nie będzie to trudne).

• W Javie więcej i łatwiej się operuje na wskaźnikach ze względu na GC, w C++ łatwiej niechcący "coś dużego skopiować" zamiast przekazać; czasem wręcz trzeba się namotać jak się STLa używa, żeby wyeliminować kopiowanie.

To tylko kwestia przyzwyczajenia, ja np. programując w Javie, Pythonie czy innym języku z wbudowanym GC nigdy nie jestem do końca pewny, czy właśnie kopiuję obiekt czy tylko tworzę nowe odniesienie ;)

• JIT efektywniej korzysta z maszyn wieloprocesorowych, bo np. GC może działać równolegle. Co oznacza, że jednowątkowy program też zyskuje troszkę na obecności drugiego rdzenia. W C++ nie.

Tu żeś imho strzelił kulą w płot, bo w C++ GC nie ma więc 'zysk' z jego braku odczuwasz niezależnie od ilości rdzeni :P

Jaka wojna?

A no taka ;)

Jakie nielogiczne przesłanki?

A no ta... może jednak nie ;)

w 90% przypadków dla kogoś kto dobrze zna Javę najlepszym wyborem jest Java

Przyznam szczerze, że jeśli miałbym kiedykolwiek użyć języka innego niż C++ to nie byłaby to Java, a wspomniany Python. Znacznie bardziej podoba mi się filozofia Pythona niż Javy (w C++ ograniczeniem jest konieczność bezpośredniej i zwięzłej kompilacji do kodu maszynowego, więc conieco można wybaczyć ;)) - zamiast ograniczać (wywalając przeciążanie operatorów czy wielokrotne dziedziczenie) zwiększa możliwości programisty (chociaż czasem aż za bardzo - brak konieczności deklaracji zmiennych przeklinałem przy każdej literówce :-[). Domyślam się, że przez większość tych udogodnień jest jeszcze wolniejszy, ale przynajmniej widzę, za co płacę ;)

Swoją drogą, ciekawi mnie wydajność tandemu Python + prekompilowane moduły pisane w C++. Będę musiał kiedyś potestować ;)

Ghostek napisał(a)

Koziołek napisał(a)

@Ghostek, pytanie kontrolne dlaczego zatem jave używano w komórkach, MDA/PDA i inszych urządzonkach o małych zasobach.

Ekhm... bo owe aplikacje nie są tak skomplikowane?

No raczej nie koniecznie. Na tego typu urządzenia pisze się tez dość skomplikowane aplikacje do np. zdalnej obsługi klienta przez "ruchomy marketing". Wiele usług "kupuj nie wychodzą z domu, nasz doradca dojedzie" opiera się właśnie na aplikacjach pisanych w javie.

Ghostek napisał(a)

Do "codziennych" pseudo skryptowych zabawek pod windą java jest wyśmienita :)

To już kwestia gustu - ja pozostaję przy zdaniu, że Python rządzi ;)

Zgadzam się. Co kto lubi ten to ma

Ghostek napisał(a)

Krolik napisał(a)

Ale nawet skompilowanie w C++ pod konkretny procesor nie gwarantuje, że ten kod będzie się wykonywał szybciej niż na JVM bo np:

• JIT może inlineować funkcje wirtualne, C++ nie.
• JIT może usuwać niepotrzebne blokady (czasem do 80%) na podstawie Escape Analysis, C++ nie.
• JIT agresywniej używa rejestrów, ponieważ nie musi się martwić o aliasing wskaźników jak w C

Tylko zauważ, że mimo wszystko Java startuje z gorszej pozycji niż języki kompilowane, bo przecież kompilacja w trakcie wykonywania swoją porcję zasobów zżera, i nie wmówisz mi że jest to do pominięcia ;) A poza tym, w C++ nie ma większego problemu z napisaniem krytycznych dla wydajności fragmentów kodu w asemblerze, więc nie trzeba zawsze zdawać się na łaskę i niełaskę kompilatora.

Java jest językiem kompilowanym! To co opisał Królik to mechanizmy w kompilatorze lub w zarządcy kolejki procesów w JVM. Co do asm to w Javie też można pisać w asm maszyny wirtualnej lub wykorzystując JNI w dowolnym innym języku.

Ghostek napisał(a)

• Alokacja i dealokacja pamięci w Javie jest średnio kilka razy tańsza niż w C++. Problem fragmentacji pamięci w Javie nie występuje.

Też zależy od tego, jak kto programuje - wiadomo, że trzymanie wielkich kontenerów wskaźników z których każdy jest alokowany dynamicznie pofragmentuje pamięć jak cholera i zeżre przy tym mnóstwo zasobów na alokację i dealokację. Z drugiej strony, jeśli trzymać dane w jednorazowo alokowanych wielkich blokach i trzymać wskaźniki na fragmenty tych bloków, to narzut związany z alokacją odpada a z fragmentacją można poradzić sobie we własnym zakresie (przy ustandaryzowanych rozmiarach fragmentów nie będzie to trudne).

Java wygrywa na tym polu bo można ją uruchomić w ten sposób, że system alokuje pamięć dla JVM jednokrotnie (i to jest kosztowna operacja), a JVM znając ilość pamięci którą ma do wykorzystania sam bez udziału systemu umie alokować w przydzielonej mu pamięci zmienne. Z drugiej strony jest to troszkę uciążliwe na początku bo nie do końca wiadomo jak podzielić pamięć i ile JVM musi jej mieć. Jednak po przeprowadzeniu kilku prostych testów można oszacować ile pamięci jest potrzebne.

Ghostek napisał(a)

• W Javie więcej i łatwiej się operuje na wskaźnikach ze względu na GC, w C++ łatwiej niechcący "coś dużego skopiować" zamiast przekazać; czasem wręcz trzeba się namotać jak się STLa używa, żeby wyeliminować kopiowanie.

To tylko kwestia przyzwyczajenia, ja np. programując w Javie, Pythonie czy innym języku z wbudowanym GC nigdy nie jestem do końca pewny, czy właśnie kopiuję obiekt czy tylko tworzę nowe odniesienie ;)

• JIT efektywniej korzysta z maszyn wieloprocesorowych, bo np. GC może działać równolegle. Co oznacza, że jednowątkowy program też zyskuje troszkę na obecności drugiego rdzenia. W C++ nie.

Tu żeś imho strzelił kulą w płot, bo w C++ GC nie ma więc 'zysk' z jego braku odczuwasz niezależnie od ilości rdzeni :P

Pierwsza część to kwestia obycia z językiem. W C++ też na początku miałem problemy z tym jak się przekazuje wartości, wskaźniki itp. Potem było łatwiej.
Druga sprawa, czyli GC, zysk jest ponieważ na etapie programowania i testowania nie musisz się martwić o ręczne dealokowanie pamięci oraz testowanie czy gdzieś nie ma wycieków, pustych wskaźników itp. Pozwala to przyspieszyć produkcję kodu i uniknąć wielu trudnych do wykrycia błędów.

Ghostek napisał(a)

Swoją drogą, ciekawi mnie wydajność tandemu Python + prekompilowane moduły pisane w C++. Będę musiał kiedyś potestować ;)

Taka jak z starym dobrym php, czyli jest znacznie szybciej, i masz te same problemy w trakcie migracji pomiędzy systemami. Zazwyczaj czegoś brakuje lub jest w niewłaściwej wersji. Typowe Dependency Hell :)

Ostatnio zacząłem bawić się Rubym i powoli stwierdzam że jest dość przydatny wszędzie tam gdzie Java jest za duża. Niezły zamiennik dla php w dodatku w pełni obiektowy.

Koziołek napisał(a)

No raczej nie koniecznie. Na tego typu urządzenia pisze się tez dość skomplikowane aplikacje do np. zdalnej obsługi klienta przez "ruchomy marketing". Wiele usług "kupuj nie wychodzą z domu, nasz doradca dojedzie" opiera się właśnie na aplikacjach pisanych w javie.

Hmm, to w takim razie zwracam honor - wiesz, od dawna nie miałem styczności z czymś bardziej skomplikowanym od Nokii 5110 więc jestem w tym temacie trochę zapóźniony ;) Przychylam się więc do odpowiedzi, że Javę stosuje się tam ze względu na przenośność.

Ghostek napisał(a)

Java jest językiem kompilowanym! To co opisał Królik to mechanizmy w kompilatorze lub w zarządcy kolejki procesów w JVM. Co do asm to w Javie też można pisać w asm maszyny wirtualnej lub wykorzystując JNI w dowolnym innym języku.

Kompilowanym, ale w trakcie wykonywania (trochę niezręcznie się wyraziłem w tamtym poście ;)) więc cały narzut związany z kompilacją zamiast zostać 'odwalony' na początku spada na użytkownika ;)

Ghostek napisał(a)

Java wygrywa na tym polu bo można ją uruchomić w ten sposób, że system alokuje pamięć dla JVM jednokrotnie (i to jest kosztowna operacja), a JVM znając ilość pamięci którą ma do wykorzystania sam bez udziału systemu umie alokować w przydzielonej mu pamięci zmienne. Z drugiej strony jest to troszkę uciążliwe na początku bo nie do końca wiadomo jak podzielić pamięć i ile JVM musi jej mieć. Jednak po przeprowadzeniu kilku prostych testów można oszacować ile pamięci jest potrzebne.

Toż mówię, że w C++ też da się tego dokonać - alokujesz pamięć blokami i dopiero potem przydzielasz obiektom, mając nad tym przy okazji znacznie większą kontrolę niż w Javie. Przy odpowiednim przeciążeniu operatorów new i delete można sprawić że to będzie zupełnie niewidoczne z poziomu programu ;)

Ghostek napisał(a)

Druga sprawa, czyli GC, zysk jest ponieważ na etapie programowania i testowania nie musisz się martwić o ręczne dealokowanie pamięci oraz testowanie czy gdzieś nie ma wycieków, pustych wskaźników itp. Pozwala to przyspieszyć produkcję kodu i uniknąć wielu trudnych do wykrycia błędów.

Cóż, też zależy, na co kto stawia przy tworzeniu projektu - w sferze moich zainteresowań, grach komputerowych, czas produkcji kodu jest znacznie mniej ważny od czasu działania. W branży zdarzały się roczne opóźnienia wybaczane firmom przez klientów, za to słabo zoptymalizowane i tnące się na high-endowym sprzęcie gry są najczęściej mieszane z błotem w pierwszej recenzji. Z tego powodu zgadzam się z tym, co napisał spc - żaden język nie jest najlepszy do każdego zastosowania.

Ghostek napisał(a)

Kompilowanym, ale w trakcie wykonywania (trochę niezręcznie się wyraziłem w tamtym poście ;)) więc cały narzut związany z kompilacją zamiast zostać 'odwalony' na początku spada na użytkownika ;)

Raczej użył bym określenia "tłumaczonym" ponieważ program jest kompilowany na bytekod, a ten tłumaczony przez VM na coś zjadliwego przez procesor.

Pascal byl swego czasu od niego sie zaczelo... a szkoda ze nie od ASM :-/ bo czas nauki pascala uwazam srednioprzydatny (no oprocz algorytmicznego myslenia w ogolniaku niewiele mi to dalo chyba...)

C/C++ wczesniej pare programow numerycznych w Fortranie i bardzo przyjemnie sie tym jezykiem poslugiwalo i naprawde szybko programy smigaly ...a byla to wersja 77 ;]

W miedzy czasie byl ASM mikroprockow ... fajna zabawa ....jak bede mial czas to popatrze na ASM x86

teraz nauka Javy i bardzo mi sie podoba :d

Nie bardzo mi szla nauka PHP i niewiele tego przyswoilem....

czolem
Oberon

Kompilowanym, ale w trakcie wykonywania (trochę niezręcznie się wyraziłem w tamtym poście ;)) więc cały narzut związany z kompilacją zamiast zostać 'odwalony' na początku spada na użytkownika ;)

No, żeby być uczciwym - to nie cały narzut tylko niewielka jego część. Chociażby odpada parsowanie wysokopoziomowego kodu i sprawdzanie poprawności programu. W runtime jest wykonywana jedynie kompilacja i optymalizacja niektórych części programu, wykonywanych najczęściej (HotSpot), zgodnie z zasadą, że 20% kodu wykonuje się przez 80% czasu. Te mechanizmy są stale dopracowywane i z kolejnymi wersjami można spodziewać się jeszcze znacznej poprawy.

Ghostek napisał(a)

Toż mówię, że w C++ też da się tego dokonać - alokujesz pamięć blokami i dopiero potem przydzielasz obiektom, mając nad tym przy okazji znacznie większą kontrolę niż w Javie.

Owszem da się. I po paru latach kodowania okazuje się, że masz nieformalnie zdefiniowaną, pełną błędów i powolną maszynę wirtualną Javy :p Strzel jeden drobny błąd we własnym alokatorze i życzę powodzenia w debugowaniu losowych segfaultów.

Cóż, też zależy, na co kto stawia przy tworzeniu projektu - w sferze moich zainteresowań, grach komputerowych, czas produkcji kodu jest znacznie mniej ważny od czasu działania. W branży zdarzały się roczne opóźnienia wybaczane firmom przez klientów, za to słabo zoptymalizowane i tnące się na high-endowym sprzęcie gry są najczęściej mieszane z błotem w pierwszej recenzji. Z tego powodu zgadzam się z tym, co napisał spc - żaden język nie jest najlepszy do każdego zastosowania.

Ostatnio widziałem strzelankę 3D na telefonie komórkowym napisaną w... Javie. Nic się nie cięło. Na wydajność w grach mają w 99% wpływ dobre algorytmy i efektywne wykorzystywanie dobrodziejstw akceleracji sprzętowej dawanej przez kartę. W Javie jedno i drugie jest możliwe (łącznie z programowaniem shaderów). Jak zrobisz zły algorytm detekcji kolizji, to i zakodowanie go w sprzęcie / asmie niewiele da. A mniejszy czas produkcji kodu, to więcej czasu na optymalizację algorytmów.