On 12.10.2014 19:53, M.M. wrote:
> On Sunday, October 12, 2014 5:25:46 PM UTC+2, bartekltg wrote:
>> On 12.10.2014 13:39, M.M. wrote:
>> Trochę porównujesz inne rzeczy.
>> Test odpalasz 10 razy. Ale pamięć dla tablic alokujesz tylko
>> raz, dla kontenerów 10 razy:>
> O to chodzi aby nie porownywac takich samych procedur - zart :D
> Powiedzmy ze porownuje wszelka wygode programowania na szablonach z
> metlikiem wskaznikow.
>
>> BTW,
>> static int data[CNT_ROWS][CNT_COLS];
>> Zdecydowanie nie leży na stosie ;-) Przez to static.
> Zgadzam sie.
>
>> Znasz rozmiary statycznie, a jednak nie używasz resize.
>> przez co alokujesz to co trzeba, ale też polowę, ćwiartkę...
> Porownuje tez listy vs wektory. Lista powinna byc sprytniejsza.

A niby czemu? Jeśli dlatego, że to powiązane kawałki tablic,
odbije się to na późniejszej wydajności dostępu.
http://en.wikipedia.org/wiki/Unrolled_linked_list (albo drzewo)

Skoro wiemy, ile danych będzie, lepiej podpowiedzieć to kontenerowi.
Nawet nie trzeba wiedzieć dokładnie, po to jest "reserve".

>> Rules jako tablica tablic możę bie być najlepsza? I tak każda
>> reguła jest inaczej używana, nie wsadzisz więc tego w pętlę.
>> Czemu nie struktura? [update, zaminiłem ma pair, przyszpieszenie
>> znikome]
> Hmmm moze, nie wiem.
>
>> > for( int i=0 ; i<LOOPS ; i++ ) {
>> > for( int i=0 ; i<CNT_ROWS ; i++ ) {
>> Nie rób tak ;-)
> Poniewaz taka sama nazwa zmiennej? Lubie tak robic, choc
> przyznaje, ze czasami tez mnie to drazni. Jednak generalnie dla
> programisty mniej zmiennych do analizy, a dla kompilatora... tez
> mniej zmiennych do optymalizowania.

Jak mniej zmiennych? Masz zmienną 'i' z pętli zewnętrznej oraz zmienna
'i' z pętli wewnętrznej. To, że pierwsze 'i' nie jest dostępne dla
Ciebie przez nazwę, nie znaczy, że nie istnieje, kompilator ma tyle
samo zmiennych:) To jedynie pułapka na programistę.


>> Wrzuciłem napisaną przez siebie wersję na vector.
>> Ciut wolniejsza, ale nie aż tak;-)
> Dzieki wielkie!
>
>
>> testRaw
>> 9.14884s sum=-191116600
>> testRaw2
>> 6.54265s sum=-191116600
>> testVectBrt
>> 10.0932s sum=-191116600
>> testVect2Brt
>> 9.03653s sum=-191116600
>
> Ciekawe dlaczego u Ciebie testRaw2 taki szybki wypadl. U mnie byl
> ciut wolniejszy. Z powodu innego sprzetu, kompilatora, opcji
> kompilacji?

-O3 -std=c++11 -march=native -mtune=native
Różnica jest też na -O2, gdy użyję
-fprofile-generate
-fprofile-use
na samym O2 nie ma. Do asma nie zaglądałem.
Dlaczego aż o tyle szybszy, pojęcia nie mam;-)


>> long long testVector()
>> {

> Musze sprawdzic, czy vector z stdliba te ma constBegin, albo metode
> 'at' zamiast operatora indeksowania[].

Ma.
At() to to samo co [] + sprawdzanie zakresu (jeśli jest poza, rzuca
specjalny wyjątek).

> W QT metoda at jest duzo szybsza
> od operatora[].

Dziwne to QT... ;-)



>> long long testVector2()
>> {
> Hmmmm, sprytniejsze.

Główne przyspieszenie jest jednak z niemaczania struktury:)


A, wersja indeksowa/wskaźnikowa ma taką zaletę, że łatwiej
(nie każde omp i kompilator wspiera iteratory) zrównoleglić
przez openmp.

Samo dodanie do testRaw

#pragma omp parallel for reduction(+:sum) //<-----
for( int i=0 ; i<CNT_ROWS ; i++ ) {
zbiło wynik do 5s (4 rdzenie).


pzdr
bartekltg

do góry

On Sunday, October 12, 2014 9:03:54 PM UTC+2, bartekltg wrote:
> A niby czemu? Jeśli dlatego, że to powiązane kawałki tablic,
> odbije się to na późniejszej wydajności dostępu.
> http://en.wikipedia.org/wiki/Unrolled_linked_list (albo drzewo)

Mnie tez Twoje uzasadnienie przekonuje, osobiscie glebiej sie nie
iteresowalem, wiec nie wiem dlaczego. W testach zwykle QList jest
minimalnie szybsze. W dokumentacji QList czytamy:
For most purposes, QList is the right class to use. Its index-based API is more
convenient than QLinkedList's iterator-based API, and it is usually faster than
QVector because of the way it stores its items in memory. It also expands to less
code in your executable.


> Skoro wiemy, ile danych będzie, lepiej podpowiedzieć to kontenerowi.
> Nawet nie trzeba wiedzieć dokładnie, po to jest "reserve".
Tak, też uważam że same allokacje już są wolne, a w przypadku wektora
może jeszcze dojść do kopiowania danych, itd.

> Jak mniej zmiennych?
Wyrazilem sie nieprecyzyjnie. Chdzilo mi o ilosc zmiennych widocznych w
poszczegolnych linijkach kodu. Jesli jedna zmienna sobie przeslonie, to
mam pewnosc, ze tej przeslonietej przez przypadek nie uzyje (zamiast
przeslaniajacej). Moim zdaniem, jest z tego ciut wiecej pozytku niz szkod.

> Masz zmienną 'i' z pętli zewnętrznej oraz zmienna
> 'i' z pętli wewnętrznej. To, że pierwsze 'i' nie jest dostępne dla
> Ciebie przez nazwę, nie znaczy, że nie istnieje, kompilator ma tyle
> samo zmiennych:)
Tak tak, nieprecyzyjnie sie wyrazilem, zmienne sa oczywiscie dwie.

> To jedynie pułapka na programistę.
Co do tego nie zgadzam sie. Kompilator i programista maja podpowiedz, ze
jedna ze zmiennych jest w danym fragmencie kodu nieuzywana.


> Różnica jest też na -O2, gdy użyję
> -fprofile-generate
> -fprofile-use
> na samym O2 nie ma. Do asma nie zaglądałem.
> Dlaczego aż o tyle szybszy, pojęcia nie mam;-)
I dobrze, szkoda czasu na zagladanie do asma :D

Generalnie jest nauka z tego taka, ze nawet dzisiejszym, dobrze
optymalizujacym kompilatorom, przydaja sie rozne podpowiedzi ze
strony programisty. Takimi podpowiedziami moze byc slowo const,
sam wskaznik zamiast zmiennej indeksujacej, przeslanianie
nieuzywanych zmiennych...


> Ma.
> At() to to samo co [] + sprawdzanie zakresu (jeśli jest poza, rzuca
> specjalny wyjątek).
Bede musial sie zainteresowac tym STLem.


> Dziwne to QT... ;-)
Nie wiem, ja lubie QT :)

> Główne przyspieszenie jest jednak z niemaczania struktury:)
Nie kumam :)


> A, wersja indeksowa/wskaźnikowa ma taką zaletę, że łatwiej
> (nie każde omp i kompilator wspiera iteratory) zrównoleglić
> przez openmp.
Nie uzywalem od pewnego czasu OpenMP, ale tez tak mi sie cos
przypomina.


> Samo dodanie do testRaw
> #pragma omp parallel for reduction(+:sum) //<-----
> for( int i=0 ; i<CNT_ROWS ; i++ ) {
> zbiło wynik do 5s (4 rdzenie).
OpenMP bardzo czesto umozliwia zrownoleglenie kodu przy zachowaniu
maksymalnej przejrzystosci.


Pozdrawiam

do góry

Zboczeńcy... :-)

do góry