Dnia Wed, 17 Apr 2013 10:42:11 -0700 po głębokim namyśle M.M. rzekł:

> On Wednesday, April 17, 2013 6:02:23 PM UTC+2, Edek wrote: [...]
>> Dalej mi się teraz już nie chce... firr, zapodaj coś do testu.
>> PS: obie kompilowane tak gcc -O3 -fwhole-program -march=native main.cpp
>> -o mb
> Zadanie jest dobre. Jest dostatecznie proste żeby się pobawić przy
> okazji dyskusji na grupie i dość skomplikowane aby dało się pobawić w
> optymalizację.

Nie mam nic do tego zadania. Do benchmarków miałbym parę uwag, typu
"nie mierzymy sleep i MOjeKOchaneSetPixel"

--
Edek

do góry

Dnia Wed, 17 Apr 2013 02:21:42 -0700 po głębokim namyśle M.M. rzekł:

>> podobny kod uwazam ze poprwany ale nie optymalizowany natomiast
>> wyrugowanie re_n im_n, skeszowanie kwadratów, rozwiniecie petli itd
>> (przepisanie na asma) nalezy juz do optymalizacji - w moim przypadku
>> optymalizacja przyniosła przyspieszenie ponad 15 X
> Ładny wynik.

Za rozsądną uważam tą co wkleiłem z operator() zaimplementowaną,
trwała 2.5s u mnie.

Skoro już szukaliście w necie implementacji, da się sprawdzić ile razy
szybsze są dostępne? Znam tylko wersję na CUDA, "troszkę" szybszą.

--
Edek

do góry

Dnia Wed, 17 Apr 2013 10:53:49 -0700 po głębokim namyśle firr kenobi
rzekł:

> W dniu środa, 17 kwietnia 2013 19:42:11 UTC+2 użytkownik M.M. napisał:
>> On Wednesday, April 17, 2013 6:02:23 PM UTC+2, Edek wrote:
>>
>> [...]
>>
>> > Dalej mi się teraz już nie chce... firr, zapodaj coś do testu.
>>
>> > PS: obie kompilowane tak
>>
>> > gcc -O3 -fwhole-program -march=native main.cpp -o mb
>>
>> Zadanie jest dobre. Jest dostatecznie proste żeby się pobawić
>>
>> przy okazji dyskusji na grupie i dość skomplikowane aby dało
>>
>> się pobawić w optymalizację.
>>
>>
> dla mnie nieco dziaczne te testy bo co to ma mierzyc - ew chyba ogolna
> wydajnosc algorytmu (tutaj wychodzi 1.4 miliarda iteracji na pare sekund
> czyli wydajnosc podobna do mojej optymalizowanej wersji na prawie 10
> letnim p4)

O ile dobrze pamiętam, ty miałeś powyżej 2 GFLOPA, to nie jest 1.4 mld
iteracji. Raczej jakieś 90mln.

--
Edek

do góry

On 17.04.2013 22:04, Edek wrote:
>
> Nie mam nic do tego zadania. Do benchmarków miałbym parę uwag, typu
> "nie mierzymy sleep i MOjeKOchaneSetPixel"

Ale to "jego kochane setpixel" jest kluczowe, bo robi jeszcze tak z 5
niepotrzebnych testów na iterację (bo wątpię, żeby wiekowe kompilatory
które używa miały choćby szansę to wyoptymalizować).


--
Pozdrawiam
Michoo

do góry

W dniu środa, 17 kwietnia 2013 22:13:19 UTC+2 użytkownik Edek napisał:
> Dnia Wed, 17 Apr 2013 10:53:49 -0700 po głębokim namyśle firr kenobi
>
> rzekł:
>
>
>
> > W dniu środa, 17 kwietnia 2013 19:42:11 UTC+2 użytkownik M.M. napisał:
>
> >> On Wednesday, April 17, 2013 6:02:23 PM UTC+2, Edek wrote:
>
> >>
>
> >> [...]
>
> >>
>
> >> > Dalej mi się teraz już nie chce... firr, zapodaj coś do testu.
>
> >>
>
> >> > PS: obie kompilowane tak
>
> >>
>
> >> > gcc -O3 -fwhole-program -march=native main.cpp -o mb
>
> >>
>
> >> Zadanie jest dobre. Jest dostatecznie proste żeby się pobawić
>
> >>
>
> >> przy okazji dyskusji na grupie i dość skomplikowane aby dało
>
> >>
>
> >> się pobawić w optymalizację.
>
> >>
>
> >>
>
> > dla mnie nieco dziaczne te testy bo co to ma mierzyc - ew chyba ogolna
>
> > wydajnosc algorytmu (tutaj wychodzi 1.4 miliarda iteracji na pare sekund
>
> > czyli wydajnosc podobna do mojej optymalizowanej wersji na prawie 10
>
> > letnim p4)
>
>
>
> O ile dobrze pamiętam, ty miałeś powyżej 2 GFLOPA, to nie jest 1.4 mld
>
> iteracji. Raczej jakieś 90mln.
>

pozniej poprawilem do 3 GFlopa

1.4 mld = 14 GFloatow (na 4 sekundy) = 3.5 GFloata na sekunde

zgadza sie - wzrosło o .5 GFloata
z jakiegos powodu, moze dluzsze itereacje kreca sie troche szybciej albo wyrzucenie
setpixeli
troche przyspieszylo reszte


co do tego kodu

vmulsd %xmm4, %xmm4, %xmm7
// re * re -> xmm7
vmovapd %xmm4, %xmm6
vmulsd %xmm3, %xmm3, %xmm5
//im*im -> xmm5
vaddsd %xmm5, %xmm7, %xmm4
// re*re+im*im -> xmm4
vucomisd %xmm0, %xmm4
// re*re+im*im > 4 ?
ja .L4

// itd

.L6:
addl $1, %eax
vsubsd %xmm5, %xmm7, %xmm4
vcvtsi2sd %eax, %xmm5, %xmm5
vaddsd %xmm6, %xmm6, %xmm6
vaddsd %xmm1, %xmm4, %xmm4
vmulsd %xmm3, %xmm6, %xmm3
vaddsd %xmm2, %xmm3, %xmm3
vucomisd %xmm5, %xmm0
ja .L7

to jest nowoczesny kod kod na avx
ale skalarny na doublach, reczne
przepisanie tego powinno przyspieszyc pewnie prawie 8 razy

do góry

Dnia Wed, 17 Apr 2013 11:47:59 -0700 po głębokim namyśle firr kenobi
rzekł:

> wypadaloby raczej czytac wersje z komantarzami - borland jakos potrafi
> cos takiego wiec i gcc chyba powinien
>
> (wstawia linijki zrodla w c w postaci komantarza + sa nazwy funkcji itp
> nieststy gubi nazwy niektorych zmiennych, (niektóre są, zdaje sie ze
> globalne sa a lokalne sobie zamienia na np $accjifia )
>
> podsumwujac jesli ktos mialby to przegladac to lepiej wygenerowac z
> nazwami ;)

http://pastebin.com/gYQ0GrPV

To nie jest output gcc, bo gcc -fverbose-asm wypluwa co innego.
objdump i gcc -c -g -O3 ... .

Sieczka Straszna jak dla mnie, ale może komuś będzie się chciało
zajrzeć.

--
Edek

do góry

On Wednesday, April 17, 2013 11:23:27 PM UTC+2, Edek wrote:
> Sieczka Straszna jak dla mnie, ale może komuś będzie się chciało
> zajrzeć.
Pomału, najpierw w cyplusplus :)

Poprawiłem błędy, pierwszy test ponad 61s w rozdzielczości 600/400px.

https://thumbs.rapidshare.com/thumbs/1024/323/A8A245
40E0BC73A595C2BE328B57E.jpg

Co oznaczają parametry chyba opisywać nie muszę.

Implementacja na razie toporna, zupełnie żadnych ulepszeń:
http://pastebin.com/bsQRUkzV

Pozdrawiam

P.S.
Sprawdzi ktos czy u niego wyglada to tak samo dla tych samych parametrów?

P.S.2.
Nie, SetPixel aż dużo nie spowalnia :)

do góry

Dnia Wed, 17 Apr 2013 14:19:17 -0700 po głębokim namyśle firr kenobi
rzekł:

> 1.4 mld = 14 GFloatow (na 4 sekundy) = 3.5 GFloata na sekunde

Ja widzę 1.4e9 na 2.5s czyli 560 M-iter/s. Licząc tak jak twój kod
wychodzi 8GFlopów z grubsza.

> zgadza sie - wzrosło o .5 GFloata z jakiegos powodu, moze dluzsze
> itereacje kreca sie troche szybciej albo wyrzucenie setpixeli troche
> przyspieszylo reszte

Zgadza się tyle: mówisz że masz procek z 2 GFlop i wyciskasz 3.5GFlop.
Jury nalicza dwa kółka wokół własnej osi przed metą za przekroczenie
II prędkości sonicznej...

> co do tego kodu
>
> vmulsd %xmm4, %xmm4, %xmm7
> // re * re -> xmm7
> vmovapd %xmm4, %xmm6 vmulsd %xmm3, %xmm3, %xmm5
> //im*im -> xmm5
> vaddsd %xmm5, %xmm7, %xmm4
> // re*re+im*im -> xmm4
> vucomisd %xmm0, %xmm4
> // re*re+im*im > 4 ?
> ja .L4
>
> // itd
>
> .L6:
> addl $1, %eax vsubsd %xmm5, %xmm7, %xmm4
> vcvtsi2sd %eax, %xmm5, %xmm5
> vaddsd %xmm6, %xmm6, %xmm6 vaddsd %xmm1, %xmm4, %xmm4
> vmulsd %xmm3, %xmm6, %xmm3 vaddsd %xmm2, %xmm3, %xmm3 vucomisd
> %xmm5, %xmm0
> ja .L7
>
> to jest nowoczesny kod kod na avx ale skalarny na doublach, reczne
> przepisanie tego powinno przyspieszyc pewnie prawie 8 razy

Mówisz o naiwnej wersji, tej pierwszej, 4.0s. W drugiej nie widzę
tych instrukcji.

W tej druga sprawa jest bardziej złożona:

te pętle mają dużo zależności. Gdy się zmieni BY_N na dużo (64 powiedzmy)
nagle obliczenia są zwektoryzowane, ale wolniejsze. Dla BY_N 12
(jak w źródle) okazuje się, że wystarcza rejestrów na to, żeby nie
wektoryzować i z jakiegoś powodu gcc nie wektoryzuje, i podejrzewam,
że słusznie. Lepiej mieć małe bloki po wiele operacji niezależnych od
siebie niż w jednym miejscu kod z wieloma zależnościami, bo tak
się ten kod wektoryzuje (przez te if-y, rezultaty...).

W dzisiejszych procesorach rejestry są na tyle niezależne, że wystarcza
jednostek obliczeniowych na pokrycie równoległe wielu operacji na
wielu nominalnych rejestrach i - może to zużywa więcej prądu, ale -
prawdopodobnie wykonuje się podobnie do wektoryzacji, a w tej pętli
nie liczy się przepustowość ale "latency" instrukcji, więc im mniej
nagromadzenia zależnych przebiegów tym lepiej. Co za różnica,
czy zrobi się 12 rejestrów po 4 double, czy 12 rejestrów i przeplot
i stałe na szczycie stosu i operacje po jednym double. I tak
po każdych obliczeniach trzeba zrobić if-a lub jakieś wektoryzowalne
adc (żeby zmienić rezultat) i być może gcc tego nie umie a ręcznie
się da.

Jak mówisz, że to da się przyspieszyć 8 razy: show me. Na pewno
pisząc assemblera da się to zrobić nie-wolniej i pewnie szybciej,
ale coś wątpię w te 8 razy.

PS. I dlaczego dkn muszę szukać tego wątku pod nazwą
"Podpis cyfrowy...". Nie dało się zainteresować kogokolwiek w
oryginalnym wątku?

PS2. Wciągnął mnie chwilowo temat ;) NA stronie Intela jest
implementacja w AVX
--
Edek

do góry

W dniu środa, 17 kwietnia 2013 22:08:12 UTC+2 użytkownik Edek napisał:
> Dnia Wed, 17 Apr 2013 02:21:42 -0700 po głębokim namyśle M.M. rzekł:
>
>
>
> >> podobny kod uwazam ze poprwany ale nie optymalizowany natomiast
>
> >> wyrugowanie re_n im_n, skeszowanie kwadratów, rozwiniecie petli itd
>
> >> (przepisanie na asma) nalezy juz do optymalizacji - w moim przypadku
>
> >> optymalizacja przyniosła przyspieszenie ponad 15 X
>
> > Ładny wynik.
>
>
>
> Za rozsądną uważam tą co wkleiłem z operator() zaimplementowaną,
>
> trwała 2.5s u mnie.
>
>
>
> Skoro już szukaliście w necie implementacji, da się sprawdzić ile razy
>
> szybsze są dostępne? Znam tylko wersję na CUDA, "troszkę" szybszą.
>
>

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

do góry

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

Wydaje się dziwne, ale prawdziwe.

do góry