On 20 Lut, 23:41, Mariusz Marszałkowski <m...@g...com> wrote:
> On 20 Lut, 21:42, bartekltg <b...@g...com> wrote:> Strzal na slepo, ale moze
zadzialac.
>
> Juz sprawdziłem z przekazywaniem parametrow przez zmienna
> golobalną, działa szybciej, ale nadal wolniej niż gąszcz if-ów.

Obok rzucilem wyniki swoich symulacji. Zupelnie odwrotne
(ale i procesor pewnie starszy).


> > > Ze swich-case w duzym kodzie dziala jeszcze wolniej, a
> > > w malym szybciej. Przynajmniej w moich testach tak bylo.
>
> > Dziwne:)
>
> Niezle zj...by dostalem za to, bo bylem przekonany ze
> switch case dziala ogolnie szybciej, a na duzych projektach
> okazalo sie ze nagle dziala wolniej. Moze procesor ma
> jakis zasob pamieci na statystyki do predykcji i na duzym
> programie ona sie wyczerpuja?

Case nie powinno byc gorsze niz drabinka if else.
Cos dziwnego. Pomacaj kompilator.
U mnie dziala 'prawidlowo' case 2%szybsze.

Moze dlatego, ze nadmiarowe 'else if( r==7 )' przeszlo w 'default:',
jedno sprawdzenie mniej, a czy kompilator to zauwazy, nie jest
oczywiste.

> Ten duzy program to cos zupelnie innego, ale tez mial
> taki gaszcz if-ow do wyboru procedury. Zaproponowalem ze
> zadziala szybciej na swich case, a tam dupa...

To jest naprawde dziwne:)

pozdrawiam
bartekltg

do góry

On 20 Lut, 23:51, bartekltg <b...@g...com> wrote:
> On 20 Lut, 21:42, bartekltg <b...@g...com> wrote:
>
> Wyniki najlepisze:
> wsk    333   100%
> case   339  101.8%
> if        348   104.5%

Kurka wodna... inny kompilator, inna maszyna no i inne wyniki. No ale
tak to już jest z językami wysokiego poziomu. Może ja walczę z
wiatrakami
próbując optymalizować kod w jezyku wysokiego poziomu.

> Niewlaczenie maksymalnego piorytetu oznaczalo, ze
> machanie myszka i drapanie sie po plecach calkowicie
> zaburza wyniki (w dowolnym kierunku).
U mnie machanie myszka zaburzalo wyniki co najwyzej o 0.1%

> Kompilator - tradycyjnie VC.
A moze vc jest na tyle sprytny, ze zobaczyl tablice const i
rozwinal inline?

Pozdrawiam

do góry

On 20 Lut, 23:56, bartekltg <b...@g...com> wrote:
> > Ten duzy program to cos zupelnie innego, ale tez mial
> > taki gaszcz if-ow do wyboru procedury. Zaproponowalem ze
> > zadziala szybciej na swich case, a tam dupa...
>
> To jest naprawde dziwne:)
>

Nie az tak dziwne. Nie wiem jak to jest naprawde, ale wyobrazam sobie,
ze w
procesorze moze byc jakas wewnetrzna tablica przewidywan skokow
warunkowych.
Na malym kodzie tablca miesci wyszystkie mozliwe rozgalezienia. Na
duzym
kodzie statystyki utworzone w jednej funkcji zostaja nadpisane przez
druga, dlatego
na duzym kodzie switch-case dzialal wolniej.

Pozdrawiam

do góry

On 21 Lut, 01:48, Mariusz Marszałkowski <m...@g...com> wrote:
> On 20 Lut, 23:51, bartekltg <b...@g...com> wrote:
>
> > On 20 Lut, 21:42, bartekltg <b...@g...com> wrote:
>
> > Wyniki najlepisze:
> > wsk    333   100%
> > case   339  101.8%
> > if        348   104.5%
>
> Kurka wodna... inny kompilator, inna maszyna no i inne wyniki. No ale
> tak to już jest z językami wysokiego poziomu. Może ja walczę z
> wiatrakami
> próbując optymalizować kod w jezyku wysokiego poziomu.

Jakbys pisal w asm zaleznosc od sprzetu byla by podobna.


> U mnie machanie myszka zaburzalo wyniki co najwyzej o 0.1%

>=dwa rdzenie?


>
> > Kompilator - tradycyjnie VC.
>
> A moze vc jest na tyle sprytny, ze zobaczyl tablice const i
> rozwinal inline?

Nie. W asm dla wskaznikow jest call na wyliczona funkcje z tabelki.

A dalej sie robi ciekawie.
Wersja z if nie przeszukuje tego 'binarnie' ale liniowo,
sprawdza, czy r==0, jak tak, to wykonuje kod i skacze na koniec,
jak nie, przeskakuje do porownanie r==1 i robi to samo.
Czyli dla r=7 wykona 8 porownan.

Wersja z case jest sprytniejsza. Dla r>6 (default, 7 i wiecej)
robi skok, w przeciwnym wypadku robi
jmp DWORD PTR $LN36@proc3[eax*4]
gdzie
$LN36@proc3:
DD $LN8@proc3
DD $LN7@proc3
DD $LN6@proc3
DD $LN5@proc3
DD $LN4@proc3
DD $LN3@proc3
DD $LN2@proc3

to tablice etykiet w rozpisanym kodzie. Czyli dokaldnie to, co
podejrzewam, chciales uzyskac tablicami.

Zrobilem jeszcze wersje z recznym wyszukiwaniem binarnym,
zawsze mamy 3 porownania.
Widac jednak duzo skakania, bo mimo tego, ze 3<8/2, to ta
wersja dziala minimalnie dluzej niz liniowe if.

Sprobuj pomoc kompilatorowi, wyrzuc definicje fp poza funkcje,
zmiej ja na int (* const fp[])(const int,const int,const int) =
{f0,f1,f2,f3,f4,f5,f6,f7};
pozmieniaj argumenty f0..f7 na const int.


Gdzie indziej w tym watku, o case>=ifelse
> > To jest naprawde dziwne:)

>Nie az tak dziwne. Nie wiem jak to jest naprawde, ale wyobrazam sobie,

Tu zupelnie nie o to chodzi. Nie siedze az tak gleboko, ale
czy case nie mozna traktowac jako lukier syntaktyczny na taka
drabinke if? W ten sposob moze byc realizowana. Czemu kompilator
mialby ja realizowac gorzej, zwlaszcza, ze to najprostrzy sposob.

Przedzej podejrzewam, ze gcc chcialo zbyt dobrze i za bardzo
'zoptymalizowalo', tworzac, jak ja w tym watku, wyszukiwanie binarne.
Co okazalo sie minimalnie gorsze. Ale czy to dobry strzal, musialbys
zerknac do wynikowego asm.

pozdrawiam
bartekltg

do góry

"Mariusz Marszałkowski" rozwiązał/a/o:
> http://pastebin.org/94340
nie chciało mi się otwierać. :-)

> Dwie wersje procedury, obie robia to samo. Jedna ma spory gaszcz if-ow i
> jest brzydka, druga ma ladne wywolanie przez wskaznik. Z pomiaru czasu
> na moim laptopie (atom N270) wynika ze ta z gaszczem if-ow wypada o 20%
> szybciej. Dlaczego wywolanie metody jest takie kosztowne? Przeciez po
> if-ach tez musi skakac, aby wybrac wlasciwy kod.
zapis składniowy nie oznacza jednoznacznego odwzorowania w języku procesora. im
lepiej użyjesz takich elementów składni danego języka, dla których kompilator posiada
przekształcenia ostatecznie syntetyzujące, tym będzie lepiej zbudowany program pod
kątem tej optymalizacji globalnej, która została wybrana.
--
-oh yea, i got it!
-oh, stupid!
D. Icke

do góry

On 21 Lut, 03:10, bartekltg <b...@g...com> wrote:
> On 21 Lut, 01:48, Mariusz Marszałkowski <m...@g...com> wrote:
>
> > On 20 Lut, 23:51, bartekltg <b...@g...com> wrote:
>
> > > On 20 Lut, 21:42, bartekltg <b...@g...com> wrote:
>
> > > Wyniki najlepisze:
> > > wsk    333   100%
> > > case   339  101.8%
> > > if        348   104.5%
>
> > Kurka wodna... inny kompilator, inna maszyna no i inne wyniki. No ale
> > tak to już jest z językami wysokiego poziomu. Może ja walczę z
> > wiatrakami
> > próbując optymalizować kod w jezyku wysokiego poziomu.
>
> Jakbys pisal w asm zaleznosc od sprzetu byla by podobna.
>
> > U mnie machanie myszka zaburzalo wyniki co najwyzej o 0.1%
> >=dwa rdzenie?
>
> > > Kompilator - tradycyjnie VC.
>
> > A moze vc jest na tyle sprytny, ze zobaczyl tablice const i
> > rozwinal inline?
>
> Nie. W asm dla wskaznikow jest call na wyliczona funkcje z tabelki.
>
> A dalej sie robi ciekawie.
> Wersja z if nie przeszukuje tego 'binarnie' ale liniowo,
> sprawdza, czy r==0, jak tak, to wykonuje kod i skacze na koniec,
> jak nie, przeskakuje do porownanie r==1 i robi to samo.
> Czyli dla r=7 wykona 8 porownan.
>
> Wersja z case jest sprytniejsza. Dla r>6 (default, 7 i wiecej)
> robi skok, w przeciwnym wypadku robi
>         jmp     DWORD PTR $LN36@proc3[eax*4]

GCC robi podobny kod. Ale... zupelnie zapomnialem, bo
my tu mamy takie wartosci ze mozna adresy skokow warunkowych
wsadzic do liniowej tablicy. Jakby bylo
swicht
case -100:
case 1000:
case 666:
case 50:
to kompilator by musial zbudowac sterte a nie tablice liniowa i
zrobic wyszukiwanie binarne.

> to tablice etykiet w rozpisanym kodzie. Czyli dokaldnie to, co
> podejrzewam, chciales uzyskac tablicami.
>
> Zrobilem jeszcze wersje z recznym wyszukiwaniem binarnym,
> zawsze mamy 3 porownania.
> Widac jednak duzo skakania, bo mimo tego, ze 3<8/2, to ta
> wersja dziala minimalnie dluzej niz liniowe if.
Gcc tez robi dla if-ow wyszukiwanie liniowe, widocznie wyszukiwanie
binarne nie oplaca sie dla tak malej ilosci.

> > > To jest naprawde dziwne:)
> >Nie az tak dziwne. Nie wiem jak to jest naprawde, ale wyobrazam sobie,
>
> Tu zupelnie nie o to chodzi. Nie siedze az tak gleboko, ale
> czy case nie mozna traktowac jako lukier syntaktyczny na taka
> drabinke if? W ten sposob moze byc realizowana. Czemu kompilator
> mialby ja realizowac gorzej, zwlaszcza, ze to najprostrzy sposob.
Jeśli mamy wartosci case 0,1,2...N to faktycznie switch - case
powinno byc najwydajniejsze. Teraz to totalnie nie wiem czemu
kilka lat temu spotkalo mnie troche przykrosci za to ze zaproponowalem
swich-case zamiast gaszczu if-ow. Tam tez mielismy case od 0 do N.
Na malym programie bylo szybciej, a na duzym wolniej.

> Przedzej podejrzewam, ze gcc chcialo zbyt dobrze i za bardzo
> 'zoptymalizowalo', tworzac, jak ja  w tym watku, wyszukiwanie binarne.
Wyglada na to ze w tym przykladzie gcc robi dokladnie to samo co VC .
Pozostaje jeszce kwestia procesora.

Pozdrawiam

do góry

On 21 Lut, 04:32, proglem <c...@s...net> wrote:
> "Mariusz Marszałkowski" rozwiązał/a/o:>http://pastebin.org/94340
>
> nie chciało mi się otwierać. :-)
>
> > Dwie wersje procedury, obie robia to samo. Jedna ma spory gaszcz if-ow i
> > jest brzydka, druga ma ladne wywolanie przez wskaznik. Z pomiaru czasu
> > na moim laptopie (atom N270) wynika ze ta z gaszczem if-ow wypada o 20%
> > szybciej. Dlaczego wywolanie metody jest takie kosztowne? Przeciez po
> > if-ach tez musi skakac, aby wybrac wlasciwy kod.
>
> zapis składniowy nie oznacza jednoznacznego odwzorowania w języku procesora. im
lepiej użyjesz takich elementów składni danego języka, dla których kompilator posiada
przekształcenia ostatecznie syntetyzujące, tym będzie lepiej zbudowany program pod
kątem tej optymalizacji globalnej, która została wybrana.

Skad wiedziec (bez zmudnych testow i pomiaru czasu) jakie wybrac
elementy skladniowe?

Pozdrawiam

do góry

On 21 Lut, 17:35, Mariusz Marszałkowski <m...@g...com> wrote:

> Skad wiedziec (bez zmudnych testow i pomiaru czasu) jakie wybrac
> elementy skladniowe?

Ogolnie nie da sie;)

1. Miec troche doswiadczenia i szczescia, jak widac na zalaczonym
obrazku, u mnie wsk dziala szybciej, u Ciebie if[*]
2. testowac najczesciej uzywane fregmenty
3. Olac takie dylematy gdy wazy sie 0.3% czasu, moze lepiej
posiedziec nad lepszym algorytmem. Bawisz sie w jakiegos rodzaju
datamining, tam sie duzo da pokombinowac zjanac dane (a nie znajac
ich nic nie wyjdzie, ciezko tam wymyslyc metody ogolne).


[*] a w te 20% na rzecz if wzdledem wskaznikow jakos uwierzyc nie
moge:)

pozdr
bartekltg

do góry

On 21 Lut, 19:42, bartekltg <b...@g...com> wrote:
> On 21 Lut, 17:35, Mariusz Marszałkowski <m...@g...com> wrote:
>
> > Skad wiedziec (bez zmudnych testow i pomiaru czasu) jakie wybrac
> > elementy skladniowe?
>
> Ogolnie nie da sie;)
>
> 1. Miec troche doswiadczenia i szczescia, jak widac na zalaczonym
>   obrazku, u mnie wsk dziala szybciej, u Ciebie if[*]
Niestety to świeta racja w językach wysokiego poziomu

> 2. testowac najczesciej uzywane fregmenty
Zgadza sie

> 3. Olac takie dylematy gdy wazy sie 0.3% czasu, moze lepiej
> posiedziec nad lepszym algorytmem. Bawisz sie w jakiegos rodzaju
> datamining, tam sie duzo da pokombinowac zjanac dane (a nie znajac
> ich nic nie wyjdzie, ciezko tam wymyslyc metody ogolne).
To mniej/więcej wygląda tak. Jest program ktory rozwiazuje
kombinatoryczne
problem o wykladniczej zlozonosci. Stosuje sie do niego wiele roznych
algorytmiczno-heurystycznych usprawnien. Niektore usprawnienia
redukuja podstawe potegi w bardzo niewielkim stopniu, raz szkodza, a
raz pomagaja, srednio np. złożoność spada z 4^N do 3.95^N. Jesli
takie usprawnienie zle zaimplementuje to przyspieszenie widac dopiero
po tygodniu obliczen.

Natomiast data mining uzywamy do opracowywania takich heurystyk.
Program zrzuca do bazy danych swoj biezacy stan, dane od uzytkownika i
szukamy zaleznosci pomiedzy danymi a tym co bylo niepotrzebnie
liczone. Cos w rodzaju jakbys probowal ulozyc kostke rubika algorytmem
z nawrotami, ale kostka rubika u kazdego klienta bylaby pomieszana
zawsze w "podobny" sposob. Czasami mozna z duzym prawdopodobienstwem
odgadnac, ze w jednym z kierunkow nie nalezy krecic kostka.

Pozdrawiam





>
> [*] a w te 20% na rzecz if wzdledem wskaznikow jakos uwierzyc nie
> moge:)
>
> pozdr
> bartekltg

do góry

On 21 Lut, 19:42, bartekltg <b...@g...com> wrote:
> [*] a w te 20% na rzecz if wzdledem wskaznikow jakos uwierzyc nie
> moge:)

proc1 = -1466166003
czas = 7516
proc2 = -1466166003
czas = 9140

Pozdrawiam

do góry