Do najpopularniejszych języków, zwłaszcza Javy i C#.
Mogą być zarówno te symulujące typowe programy, jak i szczególnie te,
które badają poszczególne typy zadań intensywnie je wykorzystując.
Sam wczoraj na przykład napisałem procedury do badania wielokrotnego
wywoływania najprostszej funkcji typu "return x++" i co się okazało?
dla tego typu zadania Java okazała się bez porównania szybsza. Chciałbym
porównać to z innymi zadaniami, może gdzieś C# będzie szybszy
(podejrzewam że przy alokacji pamięci na nowe obiekty)

do góry

On Wed, 16 Jul 2014 09:36:10 +0200, Borneq <b...@a...hidden.pl>
wrote:

>Do najpopularniejszych języków, zwłaszcza Javy i C#.
>Mogą być zarówno te symulujące typowe programy, jak i szczególnie te,
>które badają poszczególne typy zadań intensywnie je wykorzystując.
>Sam wczoraj na przykład napisałem procedury do badania wielokrotnego
>wywoływania najprostszej funkcji typu "return x++" i co się okazało?
>dla tego typu zadania Java okazała się bez porównania szybsza. Chciałbym
>porównać to z innymi zadaniami, może gdzieś C# będzie szybszy
>(podejrzewam że przy alokacji pamięci na nowe obiekty)

Mateusz Loskot napisale na tej grupie:

Witam,

Podrzucam ciekawy papier porównujący kilka języków
C++11, Fortran 2008, Java, Julia, Python, Matlab, Mathematica, R
na bazie przebiegu implementacji tego samego modelu wzrostu

http://economics.sas.upenn.edu/~jesusfv/comparison_l
anguages.pdf

A.L.

do góry

W dniu 2014-07-16 10:10, A.L. pisze:
> Podrzucam ciekawy papier porównujący kilka języków
> C++11, Fortran 2008, Java, Julia, Python, Matlab, Mathematica, R
> na bazie przebiegu implementacji tego samego modelu wzrostu
>
> http://economics.sas.upenn.edu/~jesusfv/comparison_l
anguages.pdf

Czyli najwolniejsze są języki związane ze środowiskami matematycznymi jak R.

do góry

W dniu środa, 16 lipca 2014 09:36:10 UTC+2 użytkownik Borneq napisał:
> Do najpopularniejszych języków, zwłaszcza Javy i C#.
>
> Mogą być zarówno te symulujące typowe programy, jak i szczególnie te,
>
> które badają poszczególne typy zadań intensywnie je wykorzystując.
>
> Sam wczoraj na przykład napisałem procedury do badania wielokrotnego
>
> wywoływania najprostszej funkcji typu "return x++" i co się okazało?
>
> dla tego typu zadania Java okazała się bez porównania szybsza. Chciałbym
>
> porównać to z innymi zadaniami, może gdzieś C# będzie szybszy
>
> (podejrzewam że przy alokacji pamięci na nowe obiekty)

dosyc chyba ciekawe teksty nt wydajnosci c#
itd sa np na tym blogu http://code4k.blogspot.com/
nie sa to benchmarki porórwnujace jave z c# ale jest troche ciekawych twierdzeń, nie
czytalem tego wszystkiego ale przegladalem i jest tu troche ciekawych rzeczy

do góry

co do samego tematu wydajnosci (java vs c vs c#)
to to co jest mi wiadome, krotko

1. jak kiedys robilem test java wygenerowala
kod tak samo szybki jak c (zaskoczylo mnie to ale
w sumie jest to zrozumiale i wynika z dwu powodow
- jawa kompiluje kod
- kluczowy kod byl wlasciwie kodem w c (co do literki) osadzonym w javie,

z c# pewnie jest tak samo, o tyle java i c#
sa to po prostu nadbudowy c tak samo jak c++,
kiedys o ile nie bylo kompilacji mozna bylo mowic
o pewnych roznicach teraz sa to poprostu kompilatory c z javowska i c#owska nadbudową

1. o ila ta nadbudowa jest wyciagnieta poza glowne petle (gdzie program spedza 99%
czasu)
to nie musi miec takiego znaczenia
dla szybkosci programu - moga za tu byc spowolnienia na startup programu i na wiekszy
memory stamp itp (ale ciezko mi tu podac dokladniejsze info bez praktyki w tych
jezykach)

1. rozne info pojawiaja sie na temat tego czy kompilacja JIT jest szybsza czy
wolniejsza niz
statyczna kompilacja
- jedni mowia ze jest szybasza poniewaz sprofilowanie generowanego kodu pod dany
procesor moze go zoptymalizowac (choc nie wiem
jaka to moze byc skala przyspieszenia, czy jest to np łatwe 10% łatwe 15% czy moze
czasem jest to wiecej)
- drudzy mowia ze jit jest slabszy niz statyczna kompilacja bo nie ma tyle czasu na
wygenerowanie kodu

szczerze mowiac w klasycznym duchu optymalizacji
wypadaloby traktowac JIT powaznie i doceniac ta
optymalizacje - to faktycznie ma szanse dzialac
nieco szybciej - z tym ze to zalezy tak naprawde jak beda budowane procesory, jesli
ktos produkowalby procesory z wyjatkowo dużym 'rozrzutem' to jit bylby potrzebny
jesli nie
to nie

1.[ NAJWAZNIEJSZE mz], potencjal do optymalizacji
tak naprawde jesli ktos chce optymalizowac kody
dzis to ztcw jednak musi robic wstawki w asmie
(ze wzgledu na sse) to potencjalnie mogloby sie
zmienic bo chyba nie ma problemu z mozliwoscią
zapisania jakiegos tam krzepkiego wertykalnego kodu w postaci kodu w c (nie byloby
dostepu wtedy do wszystkich operatorow sse ale wtedy mozna ratowac sie intrisincami)
- ale poki co na razie tak nie jest tak zejesli ktos chce przyoptymalizowac to chyba
musi to robic w asmie
- nie wiem jak to jest ze wstawkami w asmie w
javie i c# (?) zzasadniczo da sie to ztcso zrobic
ale nie wiem jak to jest na dziś, podobnie przydalyby sie srodki do zarzadzania
rozkladem encji w pamieci, wyrownania itp -- ogolenie ten
proces jednak to byloby cos w rodzaju u-c'owienia
czy tez u-c++owienia javy i c# tj coraz wyrazniejszego pokazywania ze w srodku ich
siedzi
c i taka java zaczynalaby sie wysokopoziomowo na
poczatku a konczyla totalnie niskopoziomowo w srodku

do góry

W sumie jeszcze moge dodac , z moich ostatnich
doswiadczen z optymalizowaniem kodu pod gcc
mozna wyroznic nastepujace etapy

0. nalezy napisac jako tako szybki 'bazowy' kod w c (chodzi o to by nie bylo tam
zadych dziwact tylko strightforward + wypadaloby jakis dobry algorytm choc sporo
przypadkow to nie sa jakies specjalne algorytmy tylko kawa na lawe-kod), ale to jest
punkt wyjscia, bazowy kod w c 'strightforward'
1. nalezy poeksperymentowac z flagami kompilatora
- niektore potrafily sporo dac (nie pamietam dokladnie jakie i ile bo nie mialem z
tym poki co az tyle praktyki, ale na pewno unsafe math rowniez chyba jeszcze cos mi
dalo jakis speedup)
2. nalezy zinlineowac kod (inlinowanie potrafilo tez oip dawac speedup, i nalezy tez
uproscic na maksa petle i sprawdzac rozne warianty profilerem
- ten punkt to jest sporo roboty bo mozliwosci i sztuczek jest sporo [nie do konca
nawet sprawdzilem co tu mozna robic bo mozna tu robic rozne rzeczy na pewno nalezy
kod masakrycznie uproscic wyciagac wyrazenie przed petle itp,
mozna tez rozwijac petle na procesowanie dwu
elementow na raz itp, moze zmienic rozklad danych w pamieci, integrowac sekwencje dwu

blokow w jeden ale sprytniejszy itd itd
3. najprawdopodobniej nalezy przepisac kod na intrinsiki w sse, jest to tez troche
roboty, sprawdzic jak to wyszlo i dalej nalezy pisac i profilowac w recznym asmie i
optymalizowac "w stylu abrasha"


w programowaniu w jawie i c# (moze i innych jezykach) jest w zasadzie to samo tylko
sa dwie roznice
-1. nalezy sie upewniec ze ten kompilowany jitem kod bedzie czystym c bez tych
wtretow spowolnien javy (na ktore dokladnie nie wiem co sie sklada ale ktos
wspominal: "automatic memory management, arrays bounds checking and resource
tracking")
-2. niekotre mozliwosci bede pewnie utrudnione w javie/c# nie wiem jak tam jest w
tych jezykach z
zapodawniaem flag kompilacji jak unsafe math albo jak jest ze wstawkami w asmie -
pewnie mozna
mw tak samo latwo jak w c odpalic punkty 1. i 2.
i z nieco wiekszymi pewnie problememi punkt 3.

w moich ostatnich optymalizacjach (dot rasteryzera tie57) punkty 1. 2. przyniosly
okolo 2X przyspieszenia (kosztem ponad tygodnia
siedzenia nad petla), punktu 3. ciagle nie zrobilem z powodu zmeczenia i tymczasowego
braku
wprawy ale da sie zrobic, nie oczekuje jednak wielkiego przyspieszenia, Calosciowe
efekty tej ciezkiej roboty to okolo 2X szybciej niz w wersji 'strightforward' - jesli
ktos lubi sie pomeczyc tydzoen lub nawet wiecej by cos dzialalo jedynie lub aż 2 razy
szybciej to warto a jesli nei to moze zostac przy wyjsciowym zwyklym kodzie
(ja akurat lubie optymalizowac nie tylko ze wzgledu na 2X szybsze dzialanie (choc mz
2X to
jest cos co sie liczy) ale tez ze wzgledu na to ze podrodze osiaga sie lepsze
zrozumienie
kodu jak i nawet dziedziny nad ktora sie z
tym kodem siedzi) - moze ew wraz z doswiadczeniem nabede jeszcze inną wizje tego jak
nalezy do tego podchodzić - wrealnych grach czy innych produkcjach drugim obszarem
optymalizaci jest optymalizacja na gpu ktora jest podobno bardziej zlozona i
trudniejsza (mnie w sumie tak przeraza ze nawet nie che sie za to brac)

do góry

W dniu 2014-07-17 12:00, firr pisze:
> 1.[ NAJWAZNIEJSZE mz], potencjal do optymalizacji
> tak naprawde jesli ktos chce optymalizowac kody
> dzis to ztcw jednak musi robic wstawki w asmie
> (ze wzgledu na sse) to potencjalnie mogloby sie

Jestem przeciwko wstawkom, są nieprzenośne. Był kod kompilowany na 32
bity, po przeniesieniu na 64 wszystko się przeniosło ale nie wstawki.
Albo w Pascalu zmiana z AnsiStringa na UnicodeStringa, z grubsza
wystarczyło zmienić deklaracje,ale nie wstawek.
Nie powinno być w ogóle możliwości, inna rzecz, że język powinien
umożliwić wszystko co chcemy załatwić wstawką. Na przykład w asmie jest
fajna instrukcja ROR do haszy a w języku tego nie ma.Albo wołanie super
dokładnego pomiaru czasu rdtsc (choć w procesorach wielordzeniowych
zostało źle to rozwiązane i zamiast wspólnego licznika każdy rdzeń ma
wiele liczników i gdy aplikacja działa na kilku rdzeniach raz odczyt
może być z jednego a raz z innego)

do góry

On Fri, 18 Jul 2014 08:08:03 +0200, Borneq <b...@a...hidden.pl>
wrote:

>W dniu 2014-07-17 12:00, firr pisze:
>> 1.[ NAJWAZNIEJSZE mz], potencjal do optymalizacji
>> tak naprawde jesli ktos chce optymalizowac kody
>> dzis to ztcw jednak musi robic wstawki w asmie
>> (ze wzgledu na sse) to potencjalnie mogloby sie

Dyc to idiotyzm

A.L.

do góry

W dniu piątek, 18 lipca 2014 09:56:01 UTC+2 użytkownik A. L. napisał:
> On Fri, 18 Jul 2014 08:08:03 +0200, Borneq <b...@a...hidden.pl>
>
> wrote:
>
>
>
> >W dniu 2014-07-17 12:00, firr pisze:
>
> >> 1.[ NAJWAZNIEJSZE mz], potencjal do optymalizacji
>
> >> tak naprawde jesli ktos chce optymalizowac kody
>
> >> dzis to ztcw jednak musi robic wstawki w asmie
>
> >> (ze wzgledu na sse) to potencjalnie mogloby sie
>
>
>
> Dyc to idiotyzm
>
>
>
> A.L.

dlaczego?

do góry

W dniu 2014-07-18 10:10, firr pisze:
>> Dyc to idiotyzm
>>
>>
>>
>> A.L.
>
> dlaczego?

Wstawki assemblerowe, to jak nadużywanie instrukcji goto. Jedyny
przypadek gdzie w C/C++ można by użyć goto to wyjście z zagnieżdżonej
pętli, chyba lepsze wyjście niż wyjście z jednej i sprawdzenie warunku
by wyjść z drugiej.
A wstawki assemblerowe - człowiek robi to co powinien robić komputer,
zmieni się typ danych i cała wstawka do przerobienia.

do góry