🚀 go-pugleaf

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