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