On Thursday, April 18, 2013 9:15:29 AM UTC+2, M.M. wrote:

> Moja implementacja spadła z 60s do 50s i to tylko po
> zastąpieniu funkcji qAbs (z qt) funkcją std::fabs.
> https://thumbs.rapidshare.com/thumbs/1024/C5F/1044D6
461373F2E2B358F73F43BAB.jpg
> Kod:
> http://pastebin.com/kS7cJXjz
> Wydaje się dziwne, ale prawdziwe.

Równolegle na procesorze i3 (dwa fizyczne rdzenie i dwa hyper) spadło z
50s do około 22s - widać ile daje hyperthreading.

https://thumbs.rapidshare.com/thumbs/1024/1E2/EFED87
57A2F1A3E94E8506435F3B5.jpg

http://pastebin.com/mB1M49BW

Pozdrawiam

do góry

W dniu czwartek, 18 kwietnia 2013 09:15:29 UTC+2 użytkownik M.M. napisał:
> On Thursday, April 18, 2013 9:01:56 AM UTC+2, firr kenobi wrote:
>
> > ile szybsza? jak ktos o czyms napomyka
>
> > a nie podaje jakichs istotnych
>
> > albo pseudoistotnych informacji
>
> > wizacych sie z tym o czym mowi to
>
> > dla mnie taka rozmowa nie ma sensu
>
> > i po prostu ten ktos nie kwalifikuje sie
>
> > do tego typu rozmowy ktorą ja bylbym w
>
> > stanie uznac za sensowną ;/ - Tak ze
>
> > proponuje albo przeklejac odpowiednie
>
> > cytaty na grupe albo jednak nie liczyc
>
> > ze bede kontynulowal tego typu
>
> > pseudorozmowy na temat bo mam lepsze
>
> > rzezy do roboty
>
>
>
> Moja implementacja spadła z 60s do 50s i to tylko po
>
> zastąpieniu funkcji qAbs (z qt) funkcją std::fabs.
>
>
>
> https://thumbs.rapidshare.com/thumbs/1024/C5F/1044D6
461373F2E2B358F73F43BAB.jpg
>
>
>
> Kod:
>
> http://pastebin.com/kS7cJXjz
>

a czemu taka dziwna petla

for( i=0 ; i<inf ; i++ ) {
const double tmp = x*x - y*y + _x;
if( std::fabs(tmp) > 2.0 ) break;
y = 2.0 * x * y + _y;
if( std::fabs(y) > 2.0 ) break;
x = tmp;
}

czy dwa warunki na fabsa sa szybsze
niz jeden na x*x+y*y>4. ? moze
cztery x<-2, x>2 y<-2, y>2 bylyby szybsze

wogole to proponuje liczyc na jaims ustalonym obszarze juz tamten poprzedni -1,-1,
1,1, lepszy oraz wywalic dzielenia z petli

do góry

On Thursday, April 18, 2013 9:44:56 AM UTC+2, firr kenobi wrote:
> a czemu taka dziwna petla
Nie wiem... znam akurat taką implementację rysowania
tego fraktala. Co jest w niej dziwne? Jaka jest lepsza?


> for( i=0 ; i<inf ; i++ ) {
> const double tmp = x*x - y*y + _x;
> if( std::fabs(tmp) > 2.0 ) break;
> y = 2.0 * x * y + _y;
> if( std::fabs(y) > 2.0 ) break;
> x = tmp;
> }


> czy dwa warunki na fabsa sa szybsze
> niz jeden na x*x+y*y>4. ? moze
> cztery x<-2, x>2 y<-2, y>2 bylyby szybsze

Jak dwa warunki, jak cztery? Nie kumam :)

Teraz zrobiłem tak:

static unsigned int computeColor( const double _x, const double _y, const unsigned
int inf ) {
double x=0, y=0;
unsigned int i;
for( i=0 ; i<inf ; i++ ) {
const double tmp = x*x - y*y + _x;
y = 2.0 * x * y + _y;
if( std::fabs(y) > 2.0 || std::fabs(tmp) > 2.0 ) break;
x = tmp;
}
if( i==inf )
return 0;
return i * 255 / (inf-1);
}

I spadło jeszcze o 2 sekundy.

Tu cały kod rysowania:
http://pastebin.com/2tSWwMrr

Tutaj efekt z pomiarem czasu:
https://thumbs.rapidshare.com/thumbs/1024/D03/ED20DB
D3BACA3EB9FAAD66E14301C.jpg

> wogole to proponuje liczyc na jaims ustalonym obszarze juz tamten
> poprzedni -1,-1, 1,1, lepszy oraz wywalic dzielenia z petli
Na takim obszarze przy większej wartości inf mam wszystko czarne:
https://thumbs.rapidshare.com/thumbs/1024/F28/9A4A63
B42170BFFB707E1970E39E1.jpg

Przy małym inf mam zbyt krótki czas i ciężko robić pomiary.

Robię na takim:
x1 = -1.40105941;
y1 = -0.00005182;
x2 = -1.40116832;
y2 = 0.00004030;
inf = 60000;


Pozdrawiam

do góry

jesli zrezygnowac z testu z kwadratem
to tutaj ten kernel z trzema mnozeniami
mozna zamianic na wersje tylko z dowma
mnozeniami

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

reim2 = (re + re) * im;

re = (re - im) * (re + im) + cRe;
im = reim2 + cIm;

// if( fabs(re) > 2.0 ) break;
// if( fabs(im) > 2.0 ) break;

if( re > 2.0 || re < -2.0
&& im > 2.0 || im < -2.0 ) break;


}

to zauwazylem ze szkoly a*a - b*b = (a+b)*(a-b) u mnie w wersji c to akurat
przyspiesza

nie wiadomo jednak czy wersja z dwoma
mul i czterema cmp (statystycznie szczesliwie mniej ) bylaby szybsza
niz kernel z 3 mul i 1 cmp

nalezaloby sprawdzic ale to musialbym
znowu pogrzebac w asmie

do góry

Zmieniłem zarządzanie wątkami, gdy się używa do wątków OpenMP
ma się praktycznie bez wysiłku kilka użytecznych opcji. Tak
więc po zastosowaniu dynamicznego przydziału zadań do wątków z
rozmiarem chunk=1 czas spadł do 14-15s.

Tu efekt:
https://thumbs.rapidshare.com/thumbs/1024/D0F/83731B
B65DA783F6EA92AB7576B7B.jpg

A tu kod rysujący/obliczający:
http://pastebin.com/rvsBJpir


On Thursday, April 18, 2013 10:42:37 AM UTC+2, firr kenobi wrote:
> jesli zrezygnowac z testu z kwadratem
> to tutaj ten kernel z trzema mnozeniami
> mozna zamianic na wersje tylko z dowma
> mnozeniami
> for(n=0; n<=max_iter; n++)
> {
> reim2 = (re + re) * im;
> re = (re - im) * (re + im) + cRe;
> im = reim2 + cIm;
> // if( fabs(re) > 2.0 ) break;
> // if( fabs(im) > 2.0 ) break;
> if( re > 2.0 || re < -2.0
> && im > 2.0 || im < -2.0 ) break;
> }
> to zauwazylem ze szkoly a*a - b*b = (a+b)*(a-b) u mnie w wersji c to akurat
> przyspiesza

U mnie czas wykonania poniższej wersji wzrósł z 14.22s do 14.61s:

static unsigned int computeColor( const double _x, const double _y, const unsigned
int inf ) {
double x=0, y=0;
unsigned int i;
for( i=0 ; i<inf ; i++ ) {
const double tmp = (x+x)*y;
x = (x-y)*(x+y)+_x;
y = tmp + _y;
if( std::fabs(y) > 2.0 || std::fabs(tmp) > 2.0 ) break;
}
if( i==inf )
return 0;
return i * 255 / (inf-1);
}



Kolejna wersja też minimalnie dłużej 14.55s:

static unsigned int computeColor( const double _x, const double _y, const unsigned
int inf ) { double x=0, y=0;
unsigned int i;
for( i=0 ; i<inf ; i++ ) {
const double tmp = x*x - y*y + _x;
y = 2.0 * x * y + _y;
if( tmp < -2 || tmp > +2 || y < -2 || y > +2 ) break;
x = tmp;
}
if( i==inf )
return 0;
return i * 255 / (inf-1);
}


> nie wiadomo jednak czy wersja z dwoma
> mul i czterema cmp (statystycznie szczesliwie mniej ) bylaby szybsza
> niz kernel z 3 mul i 1 cmp
> nalezaloby sprawdzic ale to musialbym
> znowu pogrzebac w asmie

Ja raczej nie napiszę w ASM, większość dawno temu zapomniałem :) Czy
mógłbyś podrzuć mi wersję tej procedury w asmie, tak żebym mógł ją
skompilować GCC64 bity? Czyli musiałby to być jakiś asembler osadzony.

Na razie u mnie najszybciej działa ta wersja:

static unsigned int computeColor( const double _x, const double _y, const unsigned
int inf ) {
double x=0, y=0;
unsigned int i;
for( i=0 ; i<inf ; i++ ) {
const double tmp = x*x - y*y + _x;
y = 2.0 * x * y + _y;
if( std::fabs(y) > 2.0 || std::fabs(tmp) > 2.0 ) break;
x = tmp;
}
if( i==inf )
return 0;
return i * 255 / (inf-1);
}

Z 61s udało się zejść do 14s, ale głównie przez zastosowanie OpenMP.

Pozdrawiam

do góry

W dniu czwartek, 18 kwietnia 2013 10:28:45 UTC+2 użytkownik M.M. napisał:
> On Thursday, April 18, 2013 9:44:56 AM UTC+2, firr kenobi wrote:
>
> > a czemu taka dziwna petla
>
> Nie wiem... znam akurat taką implementację rysowania
>
> tego fraktala. Co jest w niej dziwne? Jaka jest lepsza?
>
>
>
>
>
> > for( i=0 ; i<inf ; i++ ) {
>
> > const double tmp = x*x - y*y + _x;
>
> > if( std::fabs(tmp) > 2.0 ) break;
>
> > y = 2.0 * x * y + _y;
>
> > if( std::fabs(y) > 2.0 ) break;
>
> > x = tmp;
>
> > }
>
>
>
>
>
> > czy dwa warunki na fabsa sa szybsze
>
> > niz jeden na x*x+y*y>4. ? moze
>
> > cztery x<-2, x>2 y<-2, y>2 bylyby szybsze
>
>
>
> Jak dwa warunki, jak cztery? Nie kumam :)
>
>
>
> Teraz zrobiłem tak:
>
>
>
> static unsigned int computeColor( const double _x, const double _y, const unsigned
int inf ) {
>
> double x=0, y=0;
>
> unsigned int i;
>
> for( i=0 ; i<inf ; i++ ) {
>
> const double tmp = x*x - y*y + _x;
>
> y = 2.0 * x * y + _y;
>
> if( std::fabs(y) > 2.0 || std::fabs(tmp) > 2.0 ) break;
>
> x = tmp;
>
> }
>
> if( i==inf )
>
> return 0;
>
> return i * 255 / (inf-1);
>
> }
>
>
>
> I spadło jeszcze o 2 sekundy.
>
>
>
> Tu cały kod rysowania:
>
> http://pastebin.com/2tSWwMrr
>
>
>
> Tutaj efekt z pomiarem czasu:
>
> https://thumbs.rapidshare.com/thumbs/1024/D03/ED20DB
D3BACA3EB9FAAD66E14301C.jpg
>
>
>
> > wogole to proponuje liczyc na jaims ustalonym obszarze juz tamten
>
> > poprzedni -1,-1, 1,1, lepszy oraz wywalic dzielenia z petli
>
> Na takim obszarze przy większej wartości inf mam wszystko czarne:
>
> https://thumbs.rapidshare.com/thumbs/1024/F28/9A4A63
B42170BFFB707E1970E39E1.jpg
>
>

no to blad powinna byc wiekszosc
widoczna - najlepiej dawac obszar by caly zbior sie miescil

- zb m miesci sie na osi
x od gdzies tak -2 do .5 a w
y gdzies tak od -1.25 do 1.25
ja ostawiam np rysowanie od -2 do 1
a w ygreku proporcjonalnie do proporcji okna (czyli dla 500 x 400
to jest 4/5 * 3 czyli od -1.2 do 1.2
czyli konkretnie -2, -1.2 do 0.2, 1.2

jak za krotko trwa to mozna dac
5 tys iteracji i juz

>
> Przy małym inf mam zbyt krótki czas i ciężko robić pomiary.
>
>
>
> Robię na takim:
>
> x1 = -1.40105941;
>
> y1 = -0.00005182;
>
> x2 = -1.40116832;
>
> y2 = 0.00004030;
>
> inf = 60000;
>

do góry

kaszanisz te testy niesamowicie
- wez ten pierwszy z ta wersją
z dwoma mnozeniami i wywal fabsy
i wstaw warunek z czterema ifami
ale nie porownuj z 2 tylko z 2.0
bo nie jest zupelnie pewne ze to
to samo - co do wersjji asma to w
necie jest tego cala masa

ja uzywalem pierwszej (czyli 'softlab') stad :

http://locklessinc.com/articles/mandelbrot/

do góry

W dniu czwartek, 18 kwietnia 2013 11:19:53 UTC+2 użytkownik firr kenobi napisał:
> kaszanisz te testy niesamowicie
>
> - wez ten pierwszy z ta wersją
>
> z dwoma mnozeniami i wywal fabsy
>
> i wstaw warunek z czterema ifami
>
> ale nie porownuj z 2 tylko z 2.0
>
> bo nie jest zupelnie pewne ze to
>
> to samo - co do wersjji asma to w
>
> necie jest tego cala masa
>
>
>
> ja uzywalem pierwszej (czyli 'softlab') stad :
>
>
>
> http://locklessinc.com/articles/mandelbrot/

tylko nie napisz if( x > +2. || x < -2. || y > +2. || y < -2.) bo tam jest && a nie
|| - i ja bym nie uzywal dzieleń bo tam nie ku trmu specjalnej potzeby

do góry

On Thursday, April 18, 2013 11:12:19 AM UTC+2, firr kenobi wrote:

> no to blad powinna byc wiekszosc
> widoczna - najlepiej dawac obszar by caly zbior sie miescil
Nie, to nie jest z powodu błędu :)

> - zb m miesci sie na osi
> x od gdzies tak -2 do .5 a w
> y gdzies tak od -1.25 do 1.25
> ja ostawiam np rysowanie od -2 do 1
> a w ygreku proporcjonalnie do proporcji okna (czyli dla 500 x 400
> to jest 4/5 * 3 czyli od -1.2 do 1.2
> czyli konkretnie -2, -1.2 do 0.2, 1.2
Tak, u mnie też się mieści :)

> jak za krotko trwa to mozna dac
> 5 tys iteracji i juz
Mam liniowe skalowanie, każdy kolor jest dzielone przez maksymalną ilość
iteracji, czyli jak dam 60tys iteracji, to prawie wszystkie mają
wartość w pobliżu czarnej :)

Pozdrawiam

do góry

>
>
> for(n=0; n<=max_iter; n++)
> {
>
> reim2 = (re + re) * im;
> re = (re - im) * (re + im) + cRe;
> im = reim2 + cIm;
> if( re > 2.0 || re < -2.0
> && im > 2.0 || im < -2.0 ) break;
>
> }
>

to ew mialoby pewien potencjal bo
mozna rozwinac i robic testy tylko
co iles iteracji nie w kazdej

ale musialbym przepisac wlasnorecznie
na sse i sprawdzic - nie wczytywalem
sie poki co w te wersje i nie wiem
czy w niektorych z nich nie robią
podobnie, zapewne tak

do góry