🚀 go-pugleaf

W dniu 2014-07-14 00:40, Borneq pisze:
> Czy mi się zdaje, że program w Javie jest dużo szybciej wykonywany niż w
> C#? Tu pełne zaskoczenie. Kod w Javie szybszy był od Delphi, mimo że był
> bardziej skomplikowany. Natomiast kod w C# to to samo co w Javie a dużo
> wolniej.

Czy C# miałby kompilację debug i release ? Java nie ma, w np. w C++ jest 
ogromna różnica prędkości.

On 2014-07-14 00:43, Borneq wrote:
> W dniu 2014-07-14 00:40, Borneq pisze:
>> Czy mi się zdaje, że program w Javie jest dużo szybciej wykonywany niż w
>> C#? Tu pełne zaskoczenie. Kod w Javie szybszy był od Delphi, mimo że był
>> bardziej skomplikowany. Natomiast kod w C# to to samo co w Javie a dużo
>> wolniej.
>
> Czy C# miałby kompilację debug i release ? Java nie ma, w np. w C++ jest
> ogromna różnica prędkości.

W C++ ta ogromna różnica prędkości nie płynie z istnienia bądź nie 
informacji do debugowania w kodzie. Różnica płynie z włączonych 
optymalizacji kodu. A generalnie nie włącza się optymalizacji przy 
debugowaniu, ponieważ po ich włączeniu spora cześć kodu przestaje 
istnieć, inne partie są za to powtarzane wielokrotnie (aka "loop 
unwinding").
Szczególnego kopa dają metody "inline", czyli takie metody których ciała 
kompilator wstawia w miejscach wywołań, zamiast wywołań. Po typowych 
kilkunastu poziomach inlineowania, kod STLa zupełnie nie przypomina 
źródła ;-) Na tej optymalizacji opiera się wiele technik użytych w STLu, 
np traity, alokatory, czy klasy-tagi.


Java też ma tryb debugowania, ale AFAIK prawie nikt nie używa. Np. 
"assert" działa jak Delphiowe Assert(), i tak samo jego wykonanie można 
wyłączyć w trakcie kompilacji.

Inną metoda na "dubug-only code" w Javie, już popularnie używaną, jest 
takie konstruowanie wyrażeń, że w określonych warunkach część kodu nie 
jest kompilowana.
Typowe zastosowanie: wyłączenie logowania.

Po pierwsze, gdzieś deklarujesz zmienną "final static boolean DEBUG = 
true" (nazwa dowolna)

i potem w kodzie

if (DEBUG) Log.l(....);

I teraz jak przestawisz DEBUG na false, to kompilator zauważy że 
"Log.l(....)" się nigdy nie wykona, i go nie wkompiluje.


Także narzędzia do budowania potrafią tu pomóc. Np Gradle pozwala na 
różne "buildType", z czego domyślnie są dwa, "debug" i "release". A 
"buildType" ma wpływ na wiele rzeczy, między innymi można automatycznie 
zmieniać część kodu źródłowego, np zmieniać DEBUG = true w buildzie 
"debug", i DEBUG = false w buildzie "release".


A C#, dlaczego dużo wolniejszy? Stawiam raczej że coś źle 
skonfigurowałeś. Albo dany kod, algorytm, akurat nie pasuje do języka, 
zmuszając go do nieoptymalnego zachowania.


-- 
Arivald

W dniu 2014-07-14 09:15, Arivald pisze:
> Java też ma tryb debugowania, ale AFAIK prawie nikt nie używa. Np.
> "assert" działa jak Delphiowe Assert(), i tak samo jego wykonanie można
> wyłączyć w trakcie kompilacji.

W Eclipse nie zauważyłem trybów debug i release. Zamiast tego aby 
włączyć assert ustawiam parametry wirtualnej maszyny -ea.
Inaczej chyba asserty siedzą w kodzie, debugger się na nich zatrzymuje, 
tylko nie wywalają wyjątków

> I teraz jak przestawisz DEBUG na false, to kompilator zauważy że
> "Log.l(....)" się nigdy nie wykona, i go nie wkompiluje.
Ciekawe, działa jak kompilacja warunkowa

> Także narzędzia do budowania potrafią tu pomóc. Np Gradle pozwala na
> różne "buildType", z czego domyślnie są dwa, "debug" i "release". A
Używam Eclipse, do tej pory nie używałem narzędzi Ant, Gradle i Maven.

> A C#, dlaczego dużo wolniejszy? Stawiam raczej że coś źle
> skonfigurowałeś. Albo dany kod, algorytm, akurat nie pasuje do języka,
> zmuszając go do nieoptymalnego zachowania.

Ma algorytm sprawdzania czy punkt należy do wielokąta. W Pascalu i C++ 
wywoływane są procedury np. do liczenie normalnej postaci prostej 
Ax+By+C+0 z prostej przechodzącej przez dwa punkty.
W Javie i C# mocno użyte są obiekty, zamiast tylko wołania procedury 
tworzony obiekt, który dalej to wykonuje. Może Java ma szybszą alokację 
pamięci niż C#?

On 2014-07-14 09:36, Borneq wrote:
> W dniu 2014-07-14 09:15, Arivald pisze:
>> Java też ma tryb debugowania, ale AFAIK prawie nikt nie używa. Np.
>> "assert" działa jak Delphiowe Assert(), i tak samo jego wykonanie można
>> wyłączyć w trakcie kompilacji.
>
> W Eclipse nie zauważyłem trybów debug i release. Zamiast tego aby
> włączyć assert ustawiam parametry wirtualnej maszyny -ea.
> Inaczej chyba asserty siedzą w kodzie, debugger się na nich zatrzymuje,
> tylko nie wywalają wyjątków
>

Debugger to nie wiem, ale w/g specyfikacji asserty nie są kompilowane.


>> I teraz jak przestawisz DEBUG na false, to kompilator zauważy że
>> "Log.l(....)" się nigdy nie wykona, i go nie wkompiluje.
> Ciekawe, działa jak kompilacja warunkowa
>
>> Także narzędzia do budowania potrafią tu pomóc. Np Gradle pozwala na
>> różne "buildType", z czego domyślnie są dwa, "debug" i "release". A
> Używam Eclipse, do tej pory nie używałem narzędzi Ant, Gradle i Maven.
>

W Eclipse też możesz użyć, są odpowiednie pluginy.
http://marketplace.eclipse.org/content/gradle-integration-eclipse-37-43
http://maven.apache.org/eclipse-plugin.html
http://www.eclipse.org/eclipse/ant/

Dodatkowy plus że będziesz mógł budować aplikację bez Eclipse, z lini 
komend, np. w Jenkinsie.

http://en.wikipedia.org/wiki/Jenkins_%28software%29



Ja się od Eclipse odzwyczaiłem już, aktualnie już tyko InteliJ IDEA. 
Jest szybsze, nie laguje, i ogólnie jakoś tak lepiej się w nim czuję.
http://www.jetbrains.com/idea/

Choć aktualnie pracuję głównie w wersji przystosowanej do Androida, jako 
googlowe Android Studio.

-- 
Arivald

W dniu 2014-07-14 10:15, Arivald pisze:
> Ja się od Eclipse odzwyczaiłem już, aktualnie już tyko InteliJ IDEA.
> Jest szybsze, nie laguje, i ogólnie jakoś tak lepiej się w nim czuję.
> http://www.jetbrains.com/idea/

Nie wiem czy będzie tak rozbudowane jak Eclipse, które jest najbardziej 
rozbudowanym środowiskiem programistycznym. Nie zauważyłem aby było 
powolne, SWT jest szybsze od Swinga.

W dniu 2014-07-14 09:36, Borneq pisze:
> W Javie i C# mocno użyte są obiekty, zamiast tylko wołania procedury
> tworzony obiekt, który dalej to wykonuje. Może Java ma szybszą alokację
> pamięci niż C#?
Zrobiłem program testowy:
	public static boolean arith(int x,int y)
	{
		for (int i=0; i<4; i++)
		{
			double d = (double)(x+y+i)/(x*x+y*y);
			x = (int)(y+d);
			y = (int)(x+d);
		}		
		return x>y;
	}


i dla odmiany wersja z częstą alokacją:
public class Obj {
	int x,y;
	public Obj(int _x, int _y)
	{
		x = _x; y=_y;
	}
	public boolean arith() //dalej to samo

Zmierzony czas w Javie:
static:
time=63,585769 cnt=0
create objects:
time=149,328919 cnt=0

W C#:
static:
time=112.044840926103 cnt=0
create objects:
time=142.498710248631 cnt=0

Znowu zaskoczenie, z tworzeniem obiektów C# radzi sobie nawet lepiej niż 
Java, ale gorzej ze zwykłą arytmetyką. Choć w moim algorytmie była 
jeszcze większa różnica na niekorzyść C#

W dniu 2014-07-15 19:42, Borneq pisze:
> Znowu zaskoczenie, z tworzeniem obiektów C# radzi sobie nawet lepiej niż
> Java, ale gorzej ze zwykłą arytmetyką. Choć w moim algorytmie była
> jeszcze większa różnica na niekorzyść C#

Okazuje się że słabą stroną C# jest wołanie procedur
     public static boolean callinc(int x, int y)
     {
         for (int i = 0; i < 100; i++)
         {
             x = inc(y);
             y = inc(x);
         }
         return x > y;
     }

     public static int inc(int x)
     {
         return x+1;
     }
Java:
time=95,6
C# Studio:time=2640
Xamarin z NET:time=1578
Xamarin z Mono:time=1581 (dwa takie same, czyżby zawsze było Mono?)

Widać kolosalną różnicę, czyżby Java inliniowało funkcje? Natomiast C# 
ma pewnie jakiś narzut w wykonaniu

W dniu 2014-07-15 20:02, Borneq pisze:
> Widać kolosalną różnicę, czyżby Java inliniowało funkcje? Natomiast C#
> ma pewnie jakiś narzut w wykonaniu

Nie wiem, czy chodzi o narzut, bo w Delphi jest 1140, zmiana na inline: 
413, dalsza zmiana na inline wołającej: 408
w trybie release Delphi: 376, inline 63, cała inline 69 (nawet gorzej)
inc_ jako assembler: podobnie jak inline
Natomiast C++ debug: 5050 a release 70

On 2014-07-16 09:06, Borneq wrote:
> W dniu 2014-07-15 20:02, Borneq pisze:
>> Widać kolosalną różnicę, czyżby Java inliniowało funkcje? Natomiast C#
>> ma pewnie jakiś narzut w wykonaniu
>
> Nie wiem, czy chodzi o narzut, bo w Delphi jest 1140, zmiana na inline:
> 413, dalsza zmiana na inline wołającej: 408
> w trybie release Delphi: 376, inline 63, cała inline 69 (nawet gorzej)
> inc_ jako assembler: podobnie jak inline
> Natomiast C++ debug: 5050 a release 70
>

Tak BTW, C++-ów jest jak mrówków, mają różna optymalizacje. Zresztą już 
samo "release" C++ w jednym kompilatorze może się diametralnie różnić, 
zależnie od włączonych optymalizacji. Taki prosty przypadek jak podałeś 
mógł być zoptymalizowany przez rozwinięcie pętli, i równoległą artmetykę 
przy użyciu SSE.

Ogólnie porównywanie prędkości rożnych języków w tak prostych 
przypadkach daje dziwne wyniki, z powodów różnych optymalizacji i 
różnych obowiązkowych narzutów.

Np w Delphi masz spory narzut na tworzenie obiektu, po pierwsze w 
alokacji (np obowiązkowa VTABLE), kiedy w C++ jest możliwe że obiekt 
alokuje tylko jeden bajt, zresztą go nie używając, bo alokacja jest 
tylko żeby obiekt posiadał unikalny adres.


Przy wywołaniach procedur największy narzut jest najczęściej na ramkę 
stosu i inicjalizację zmiennych na stosie (jeśli dany język 
inicjalizuje, np C++ tego nie robi, Delphi też nie). I tu C++ pokazuje 
swoją siłę, ponieważ po inline metody nie ma wywołania metody, ergo nie 
ma ramki i całego narzutu.

Za to Delphi, jeśli tylko używasz w metodzie stringa, rekordu, 
interfejsu lub obsługi wyjątków, automatycznie dodaje do funkcji kod 
finalizujący zmienne i obsługujący wyjątki, dlatego narzut może być spory.


Co do Javy:
"czyżby Java inliniowało funkcje" - tak i nie. Kompilator Javy nie robi 
tego. Ale maszyna wirtualna Javy, w trakcie kompilacji bytecodu to 
natywnego, ma prawo sobie tak zoptymalizować. Zresztą optymalizacje JVM 
są dużo bardziej zaawansowane. Np. JVM często obserwują działającą 
aplikację, i optymalizują niektóre ścieżki na podstawie częstotliwości 
ich wykonania.
Dlatego w niektórych serwerach aplikacyjnych Javy jest coś takiego jak 
"warming up", czyli serwer przez jakiś czas po restarcie nie obsługuje 
żądań, tylko wykonuje fragmenty kodu dając czas JVM na zauważenie że są 
istotne, i zoptymalizowanie działania.

Java jest dość wrażliwa na alokację obiektów, ale nie tylko chodzi o 
samą alokację, co o garbage collector - jego cykle czyszczenia potrafią 
całkiem mocno spowolnić aplikację. W aktualnych maszynach GC został 
mocno zoptymalizowany, tak że nie jest to już aż taki problem.


C# nie znam, nie wiem co mogło wpłynąć na akurat takie wyniki.

-- 
Arivald