[hbpitero]

Nawiązując do:

http://www.wykop.pl/wpis/5853157/programowanie-heheszki-moja-wersja-pokaz-spoiler/#comment-11769715

Faktycznie napisałem bąbelkowe dla C++ i Javy, bo od dawna się przymierzałem do takich mniejszych testów, żeby faktycznie przekonać się o szybkości współczesnej Javy.

Spodziewałem się, że Java będzie 2-3x wolniejsza (czyli nadal niesamowicie szybka, porównując do jakiś phpków itd.).

Nie zawiodłem się :D


@xaxes

#programowanie #java #c++ #cpp #wydajnosc

[I.....x]

@hbpitero: Zależy w jaki sposób są generowane liczby.

[x.....s]

@hbpitero: Pokaż kod. Rozumiem że mierzysz czas samego sortowania, a nie sortowania+odpalania JVM.

[A.....k]

@Incognix: A przydzielanie pamięci na dane nie ma znaczenia?

@hbpitero:

[n.....l]

@hbpitero: nie alokowałeś czasami dynamicznie pamięci w C? malloc jest strasznie wolny

[hbpitero]

@xaxes: Oczywiście, przecież z odpalaniem JVM mogło by i kilka sekund dojść. Kod sortowania dosłownie identyczny

for (i = 0; i < n; i++) {

for (j = 1; j < ( n - i ); j++)

[hbpitero]

@Analityk: Nie ma. Czas przydziału pamięci wyciągnąłem poza pomiar czasu.

[hbpitero]

@nvll:

const int n = 50000;

int a[n];

[I.....x]

@hbpitero: Tylko, że niektóre generatory losowe generują te same ciągi liczb za każdym razem.

[a.....r]

Rozumiem że mierzysz czas samego sortowania, a nie sortowania+odpalania JVM.

@xaxes: Typowy błąd robiony przez programistów c/c++..

[hbpitero]

@Incognix: Czy to coś zmienia? przy tak dużej tablicy itd. i tak branch prediction za dużo tutaj nie zdziała

[RRybak]

@hbpitero:

[a.....r]

@hbpitero: JVM musi się "rozkręcić". Potem kod powinien działać z mniej więcej tą samą szybkością.

[hbpitero]

@archlinuxuser: kod wygrzałem (zresztą dzieje się to praktycznie od razu przy takiej ilości iteracji), potwierdzone outputem z JIT.

Co najciekawsze, myślałem, że JIT kompiluje licząc ilość wywołań metody,a tu kompilacja następuje w trakcie kręcenia sortowania już w pierwszym wywołaniu sortowania, i to dosyć wczesnie bo pierwsze rozgrzewające sortowanie trwa zaledwie 5 sekund

[hbpitero]

@RRybak: Co masz na myśli?

[a.....r]

@hbpitero: To zachowanie JIT zależy też od tego, czy uruchamiasz program w trybie serwera czy domyślnym.

[RRybak]

@hbpitero: po prostu nie chce mi się wierzyć :) Nawet jeśli Java jest kompilowana do bytecodu, to i tak jest to maszyna z pewną interpretacją. Może zyskać na indeksach - być może obsługuje takie drobne incrementacje i dekrementacje adresów jakoś natywnie. Ale 9 sekund to aż za dużo wg mnie na taki algorytm w kodzie czysto maszynowym, kompilujesz w trybie 32bit? Jutro w robocie zrobię sobie testy.

[hbpitero]

@RRybak: Sęk w tym, że java może to skompilować lepiej niż C++. bytecod działa tylko przez pierwsze"ileś" iteracji, a potem kod jest kompilowany do maszynowego, "tak samo" jak C++.

"tak samo" bo java ma przewagę, że kompiluje dopiero PO uruchomieniu programu - może sobie zoptymalizować kod maszynowy dokładnie pod komputer na którym właśnie pracuje, wykorzystać idealnie wielkość cachu w procesorze, zastosować w miarę możliwości SSE itp. itd.

To tylko prosty

[acetone]

@hbpitero: Z jakimi opcjami kompilowales c++?

[hbpitero]

@acetone: Wszystko bez żadnej specjalnej opcji (java jak i c++). Po prostu standardowe JDK javy pod windows i g++ z MinGW

czyli "g++ a.cpp" odpowiednio do "javac a.java"

[E.....m]

@hbpitero: a teraz dawaj delphi :D